必须用AFTER行级触发器，因INSERT时OLD无效、DELETE时NEW无效，仅UPDATE两者俱全，而版本控制需完整捕获旧值与新值；TG_OP大小写敏感须全大写判断；历史表需valid_from/valid_to字段及唯一索引；禁止SELECT OLD.*插入；并发版本号冲突需应用层CAS解决。

必须用 AFTER 行级触发器，BEFORE 在 INSERT 时拿不到 OLD、DELETE 时拿不到 NEW，根本无法完成版本快照的完整捕获。

为什么只能用 AFTER FOR EACH ROW

行级版本控制的核心是“每次变更都存一份旧值 + 新值”，而 OLD 和 NEW 的可用性严格受限于操作类型：

• INSERT：只有 NEW 有效，OLD 是未分配状态，读取会报错 record "old" is not assigned
• DELETE：只有 OLD 有效，NEW 为空，强行引用直接崩溃
• UPDATE：两者都可用——这正是版本衔接的关键：把 OLD 存为历史快照，再让 NEW 成为当前行

所以 BEFORE 触发器在 INSERT 和 DELETE 场景下天然缺失一端数据，无法构造完整版本链。只有 AFTER 能确保所有变更已落地，OLD/NEW 均可安全访问。

TG_OP 大小写敏感且必须显式判断

触发器函数里靠 TG_OP 区分操作类型，但它返回的是全大写字符串，任何大小写偏差都会导致逻辑跳过：

• ✅ 正确：IF TG_OP = 'INSERT'、ELSIF TG_OP = 'UPDATE'
• ❌ 错误：IF TG_OP = 'insert' 或 IF TG_OP ILIKE 'update'（ILIKE 不生效，TG_OP 是 text 类型但比较不走模糊匹配）
• 常见现象：历史表空空如也，查日志发现条件始终不满足——八成是写成了小写

建议统一用全大写 + 单引号包裹，并在函数开头加 RAISE NOTICE '%', TG_OP; 快速验证执行路径。

历史表结构和索引不能省

版本控制不是只把数据塞进去就完事，结构设计直接影响查询效率和数据一致性：

• 必须包含成对时间字段：valid_from TIMESTAMP WITH TIME ZONE DEFAULT NOW() 和 valid_to TIMESTAMP WITH TIME ZONE；单时间戳无法表达“生效区间”
• 必须建唯一索引：CREATE UNIQUE INDEX idx_hist_id_valid_from ON user_history (id, valid_from)，否则同一主键可能在相同时刻出现多条活跃记录
• 禁止用 * 插入：INSERT INTO user_history SELECT OLD.* 看似省事，但一旦主表加字段或历史表多出 op_type 字段就会失败；务必显式列出字段名
• 字段名冲突要提前规避：如果主表已有 version 字段，历史表建议用 plt_version，避免 NEW.version := OLD.version + 1 赋值时因同名字段覆盖出错

并发更新时版本号冲突必须由应用层兜底

触发器能自动递增版本号，但无法解决两个事务同时读到 OLD.version = 5 并都设 NEW.version = 6 的竞争问题：

• 数据库层面无法原子化“读旧值→算新值→写新值”三步，这是典型的 ABA 问题
• 真正可靠的方案是应用层用 UPDATE ... SET version = version + 1 WHERE id = ? AND version = ? 带条件更新，失败则重试
• 触发器只负责：插入历史快照、填充 valid_from、设置默认 op_type；版本号生成逻辑应尽量移出触发器

最易被忽略的一点：触发器内写的每一条 INSERT INTO history 都在主事务中同步执行，批量更新百万行时，历史表写入会撑爆 WAL、拖慢主表响应——这不是触发器写得不对，而是它本就不适合替代异步归档。真要扛量，得切到逻辑复制或 CDC 工具。