Postgres中current_timestamp在函数与SQL语句的表现差异及配置问询

一、差异是否符合预期？ #

答案是符合预期，核心原因在于Postgres中current_timestamp的行为完全依赖于当前数据库会话的时区设置，而非数据库服务器本身的时区：

• 当你在数据库服务器上直接执行select current_timestamp时，你的客户端（比如psql）大概率继承了操作系统的CET时区，数据库会话的时区也随之被设为CET，因此current_timestamp会返回转换为CET时区的时间。
• 而通过Java的CallableStatement调用函数时，JDBC连接默认没有显式设置会话时区，此时会继承数据库服务器的UTC时区，导致函数内的current_timestamp返回UTC时区的时间。

简单来说：current_timestamp的输出结果是当前会话时区下的时间，不同会话的时区配置不同，结果自然会有差异。

二、如何让函数与直接SQL表现一致？ #

你可以通过以下几种方式实现统一：

1. 在JDBC连接时显式设置会话时区（推荐） #

让Java连接的会话时区和你直接执行SQL时的客户端时区保持一致：

• 在JDBC URL中添加时区参数：

  String url = "jdbc:postgresql://your-db-host:5432/your-db?timezone=CET";
  Connection conn = DriverManager.getConnection(url, user, password);
  

• 或者在连接建立后执行SQL设置时区：

  try (Statement stmt = conn.createStatement()) {
      stmt.execute("SET TIME ZONE 'CET'");
  }
  

这样整个JDBC会话的时区都会是CET，函数内调用current_timestamp就会返回CET时间，和直接执行SQL的结果完全一致。

2. 修改函数，强制绑定CET时区 #

如果你希望函数不受会话时区影响，始终返回CET时间，可以在函数中显式转换时区：

CREATE OR REPLACE FUNCTION get_current_time()
RETURNS TIMESTAMPTZ AS $$
BEGIN
    RETURN current_timestamp AT TIME ZONE 'CET';
    -- 等价写法：now() AT TIME ZONE 'CET'
END;
$$ LANGUAGE plpgsql;

这种方式的缺点是时区硬编码，后续如果需要切换时区，必须修改函数代码。

3. 修改Postgres全局默认时区（不推荐） #

你可以在Postgres配置文件postgresql.conf中修改timezone参数为CET，这样所有新建立的会话默认都会使用CET时区。但这种方式会影响所有连接到数据库的应用，除非你确定所有业务都依赖CET时区，否则不建议使用。

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