timestamptz与timestamp with time zone完全等价，前者是后者的标准缩写；建表时应直接选用timestamptz，Navicat界面下拉列表中仅显示该别名，手动输入全称易被识别为自定义类型而报错。
PostgreSQL建表时选timestamp with time zone还是timestamptz？
两者完全等价，timestamptz是timestamp with time zone的缩写别名，PostgreSQL内部统一处理。Navicat 设计表界面里下拉类型列表中通常只显示timestamptz，直接选它就行——别手动输全称，否则可能被 Navicat 当作自定义类型忽略或报错。
关键不是名字，而是行为：只要用了这个类型，插入'2026-10-21 15:30:00'这种无时区字符串时，PostgreSQL 会按当前会话timezone解释并转成 UTC 存储；查询时再按会话时区转回本地时间显示。所以必须确保会话时区设对（见下一条）。
Navicat连接PostgreSQL后SET timezone = 'Asia/Shanghai'为什么每次新开标签都失效？
因为SET只作用于当前数据库会话，Navicat 每次新建查询窗口（包括同步、导出、右键“打开表”）都建立新会话，旧设置不继承。
真正能“自动生效”的方式只有两种：
- 在连接属性 → 「高级」页 → 填入
Initial statement：SET timezone = 'Asia/Shanghai';（注意结尾分号不能少） - 若用云数据库（如阿里云 RDS），该字段常被锁定，此时只能靠客户端每次连上后手动执行这句，或改用命令行工具 psql 配置
.psqlrc
验证是否生效：执行SELECT now();，结果应显示东八区时间（如2026-10-21 15:30:00.123+08），而不是+00。
为什么字段设了timestamptz，但Navicat里查出来还是UTC时间？
典型现象：服务器postgresql.conf写了timezone = 'Asia/Shanghai'，但 Navicat 查now()仍返回+00时间——这不是数据库没生效，而是 Navicat 连接时没把时区传过去，服务端只能用默认UTC初始化会话。
根本原因在于 PostgreSQL 的时区协商机制：客户端不声明时区，服务端就按配置文件设的值启动会话；但 Navicat 默认不发timezone参数，也不执行SET，所以哪怕你改了postgresql.conf，它也看不到。
解决路径很窄：
- 服务端强制：改
pg_hba.conf对应规则末尾加timezone=Asia/Shanghai（仅 PostgreSQL 14+ 支持） - 客户端兜底：必须用
Initial statement或每次手动SET，没有中间选项
别指望 Navicat 的「默认值」栏填now()能绕过——那只是插入时的表达式，不影响存储和查询时的时区转换逻辑。
PostgreSQL中timestamptz字段能不能像MySQL那样勾选“自动更新”？
不能。Navicat 对 PostgreSQL 不提供图形化「自动更新时间戳」开关，MySQL 那套界面逻辑在 PostgreSQL 里不存在。
要实现update_time随每次UPDATE自动刷新，唯一可靠方式是写触发器：
- 在 Navicat 中右键表 → 「设计表」→ 切到「触发器」页 → 新建触发器，函数体用
NEW.date_updated := NOW(); - 或者手写 SQL：
CREATE OR REPLACE FUNCTION update_updated_at_column() RETURNS TRIGGER AS $BODY$ BEGIN NEW.date_updated = NOW(); RETURN NEW; END; $BODY$ LANGUAGE plpgsql;，再绑定到表上
注意：CURRENT_TIMESTAMP作为列默认值只影响插入，不负责更新；想兼顾插入+更新，必须用触发器或DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP（这是 MySQL 语法，PostgreSQL 不支持）。
