current_timestamp看似通用实则危险，因sql server中它等价于getdate()、返回无时区datetime且每次调用值不同，而postgresql中它等价于transaction_timestamp()、返回带时区timestamptz且事务内值恒定，导致实时性逻辑迁移后静默出错。
没有真正能“开箱即用”跨 PostgreSQL 和 SQL Server 的时间函数——只要脚本里出现 GETDATE()、CURRENT_TIMESTAMP 或 DATEADD() 这类写法，就注定只能跑在一个库里。
为什么 CURRENT_TIMESTAMP 看似通用，实则危险？
CURRENT_TIMESTAMP 在两个库都存在，但行为差异藏在细节里：
- SQL Server 中它是
GETDATE()的 ANSI 别名，返回DATETIME（精度 3.33ms），不带时区 - PostgreSQL 中它等价于
transaction_timestamp()，返回timestamptz（带时区的时间戳），且整个事务内值不变 - 如果你在 PostgreSQL 事务里连查两次
CURRENT_TIMESTAMP，得到的是同一时间；SQL Server 每次调用都是新值
这种“同名不同命”的情况，会让依赖“实时性”的逻辑（比如日志打点、超时判断）在迁移后静默出错。
哪些函数能靠标准语法+类型转换勉强共存？
只有极少数操作能靠 ANSI SQL 标准兜底，但需主动约束用法：
-
NOW()：PostgreSQL 原生支持；SQL Server 不认——必须改写为GETDATE()才能运行，不能直接混用 -
EXTRACT(YEAR FROM col)：PostgreSQL 和 Oracle 支持；SQL Server 用DATEPART(yy, col)，MySQL 用YEAR(col)，三者语法不兼容 -
INTERVAL运算：PostgreSQL 允许col + INTERVAL '1 day'；SQL Server 必须用DATEADD(day, 1, col)；二者无法共存于同一语句
真正能跨库的只有字面量时间比较，例如：WHERE order_time > '2026-08-27'——但这不算“函数”，只是字符串转日期的隐式转换，且依赖列类型和数据库默认解析规则。
跨平台时间计算唯一可行路径：用 CAST + 字符串中立化
想让同一段 SQL 在两个库都执行成功，核心是绕过函数，改用类型转换和固定格式字符串：
- 避免所有时间函数，改用带时区的 ISO 8601 字符串字面量：
'2026-08-27T19:49:00+08' - 用
CAST('2026-08-27' AS DATE)替代CONVERT(DATE, '2026-08-27', 103)或TO_DATE('2026-08-27', 'YYYY-MM-DD')——CAST是 ANSI 标准，在两库均有效 - 日期加减必须拆成应用层逻辑：数据库只做字符串→日期转换和比较，加减运算由程序代码完成（如 Python 的
datetime.timedelta）
硬要在 SQL 层做跨库时间计算，等于主动放弃可维护性。真正的跨平台不是“一个 SQL 脚本跑两家”，而是“一套语义，两套实现”——把时间逻辑下沉到 ORM 或中间层，数据库只负责存储和简单过滤。
