必须用AFTER触发器，因为BEFORE在INSERT时OLD为空、DELETE时NEW为空，无法获取变更所需的双快照；有效期管理需valid_from和valid_to成对字段，且须建(id, valid_from)唯一索引。
必须用 AFTER 行级触发器，BEFORE 在 INSERT 时拿不到 OLD、DELETE 时拿不到 NEW，根本无法完成有效期成对写入。
为什么一定要用 AFTER 而不是 BEFORE？
有效期管理依赖“变更瞬间的旧值+新值”双快照：INSERT 需记 NEW.* 并设 valid_from = NOW()、valid_to = NULL；UPDATE 必须先将 OLD.* 的 valid_to 更新为当前时间，再插入 NEW.*（valid_to 仍为 NULL）；DELETE 则需存 OLD.* 并设 valid_to = NOW()。这些操作都要求数据已确定——BEFORE 触发器在写入前执行，OLD 在 INSERT 中为空、NEW 在 DELETE 中为空，直接报错或漏写。
-
BEFORE INSERT：OLD不存在，无法做历史回填 -
BEFORE DELETE：NEW不存在，无法判断是否要保留快照 -
AFTER确保OLD和NEW始终可用，且事务上下文完整
历史表结构必须含 valid_from/valid_to 成对字段
单个时间戳（比如只存 updated_at）无法表达“某条记录在什么时间段内有效”。必须用 valid_from 和 valid_to 组合建模逻辑生命周期：
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
-
valid_from类型应为TIMESTAMP WITH TIME ZONE，默认NOW() -
valid_to类型同上，允许NULL，表示“当前仍有效” - 严禁用
BOOLEAN is_current替代——并发更新时极易状态竞争，导致多条记录同时is_current = true - 必须在
(id, valid_from)上建唯一索引，防止同一主键在相同时刻出现多条活跃记录
触发器函数里别偷懒用 SELECT * 或 EXECUTE 动态拼表名
历史表字段通常比主表多（如加了 op_type、valid_from），用 * 插入会因列数不匹配直接报错；动态拼接表名则引入 SQL 注入和调试黑洞。
- 错误写法：
INSERT INTO hist_users SELECT OLD.*—— 若历史表多了op_type字段，就失败 - 正确写法：
INSERT INTO users_history (id, name, email, valid_from, valid_to, op_type) VALUES (OLD.id, OLD.name, OLD.email, OLD.valid_from, NOW(), 'U'); - 真要跨多个历史表（如分租户场景），必须用
format('%I', table_name)转义标识符，禁用字符串拼接
批量操作时小心 WAL 和事务膨胀
触发器在主 DML 事务内同步执行。如果一次 UPDATE 百万行，每行都触发一次历史写入，会显著拖慢主事务、撑爆 WAL 日志、卡住 pg_stat_activity 中的长时间运行查询。
- 上线前务必压测：模拟真实批量更新量，观察事务延迟和 WAL 生成速率
- 避免在高频小更新场景（如计数器自增）上启用有效期触发器
- 若业务允许，可考虑异步落库（如通过
pg_notify+ 后台 worker），但会丢失严格事务一致性
最容易被忽略的是 valid_from 不能复用 created_at——它必须反映逻辑生效时间，而非插入时间；而 valid_to = NULL 的语义必须与应用层读取逻辑完全对齐，否则查“当前有效记录”时会漏行或错行。
