DB2转PostgreSQL：CURRENT_TIMESTAMP迁移替代方案确认

结论先行：statement_timestamp()是替代DB2 CURRENT_TIMESTAMP的精准选择，下面拆解为什么以及替换后的注意事项：

核心行为对比 #

先明确两边函数的核心差异：

• DB2 CURRENT_TIMESTAMP：每条语句执行时的实际时间戳，同一事务内的多条INSERT/UPDATE语句，每行的时间戳会随语句执行时间变化。
• PostgreSQL CURRENT_TIMESTAMP：返回事务开始时间，同一事务内所有调用结果完全一致，和DB2行为完全不符，这也是你觉得官方转换指南太笼统的原因。

为什么选statement_timestamp() #

PostgreSQL的statement_timestamp()刚好匹配DB2的行为：

• 它返回当前SQL语句开始执行的时间，同一事务里的不同语句会得到不同的时间戳。
• 单条语句内多次调用statement_timestamp()，结果也完全相同（比如单条INSERT插入多行时，所有行的时间戳一致），这和DB2的CURRENT_TIMESTAMP在单条语句中的表现一致。

为什么不选clock_timestamp() #

clock_timestamp()返回的是函数调用瞬间的精确时间，如果在单条语句中多次调用（比如大结果集的每行都调用），可能得到不同的时间值，这和DB2中CURRENT_TIMESTAMP在单条语句内保持一致的行为不符，所以不适合作为替代。

替换后的副作用 #

只要你的业务逻辑是需要记录语句执行时间（而非事务启动时间或更细粒度的实时时间），替换statement_timestamp()后几乎没有副作用：

• 完全对齐DB2的时间戳生成逻辑，不会出现同一事务内多条语句时间戳相同的问题。
• 兼容所有SQL场景：INSERT、UPDATE、SELECT中的时间戳生成都和DB2表现一致。

内容的提问来源于stack exchange，提问作者Fabian