不能仅靠触发器实现完整版本管理，它仅支持自动快照和版本号递增；历史一致性、查询回溯、软删等需应用层或额外架构补充，且需注意TG_OP大小写敏感、NEW/OLD可用性限制、索引优化及并发冲突等问题。
不能靠触发器单独实现完整版本管理系统，它只能承担“自动快照”和“版本号递增”这类确定性动作；历史数据一致性、查询回溯、软删语义必须由应用层或额外架构补全。
触发器里怎么拿到操作类型（INSERT/UPDATE/DELETE）
用 TG_OP 内置变量，它是大小写敏感的字符串，值为 'INSERT'、'UPDATE' 或 'DELETE'。别直接写 IF TG_OP = 'update'，小写会永远不匹配。
常见错误现象：触发器函数看似执行了，但历史表没插入数据——大概率是 TG_OP 字符串比较写错了大小写，或者漏了单引号。
使用场景举例：
- INSERT 时初始化
version = 1和created_at - UPDATE 时查
OLD.version，设NEW.version = OLD.version + 1 - DELETE 时若走软删，可插入快照后
RETURN NULL阻止物理删除
行级触发器中访问新旧数据的限制
NEW 和 OLD 只在对应操作中可用：INSERT 没有 OLD，DELETE 没有 NEW，UPDATE 两者都有。试图在 INSERT 里读 OLD.id 会报错 record "old" is not assigned。
性能影响：如果历史表（如 users_history）没有主键或索引，UPDATE 触发器里 INSERT INTO users_history SELECT OLD.* 会随数据量增长明显拖慢主表写入速度。
实操建议：
- 历史表必须建索引，至少在
(id, plt_dataversion)上建唯一复合索引 - 避免在触发器里做复杂计算或跨库查询，PL/pgSQL 不适合高并发下的长事务
- 字段名冲突要提前规避，比如原表已有
version，就改用plt_dataversion，否则NEW.version赋值会失败
为什么不能只靠触发器还原任意时间点的数据
触发器只保证“每次变更都存一份快照”，但它不记录变更之间的依赖关系，也不保存事务边界。比如一个事务里更新了 3 行，触发器会插入 3 条历史记录，但你无法知道这 3 条属于同一个逻辑操作。
容易踩的坑：
- 并发 UPDATE 同一行：两个事务同时读到
OLD.version = 5，都设NEW.version = 6，导致版本号冲突 - 批量 UPDATE（
UPDATE t SET x = x + 1 WHERE y > 100）会为每行触发一次，但你无法从历史表反推出“这批更新是由哪个业务动作发起的” - 触发器不捕获 DDL，表结构变了（比如删了
age字段），旧历史记录里的age值还在，但新插入的历史行会因字段缺失报错
真正需要时间点恢复时，得配合 pg_dump -t users_history --inserts 定时导出，或用 WAL 归档 + PITR，而不是指望触发器日志。
触发器函数部署后怎么验证是否生效
别只看 SELECT tgname FROM pg_trigger，那只能说明对象存在。必须实测 DML 并查历史表：
执行 INSERT INTO users (name) VALUES ('alice'); 后，立刻查 SELECT * FROM users_history WHERE id = currval('users_id_seq'); 看是否有一条 plt_dataversion = 1 的记录。
关键检查点：
- 触发器绑定的是
BEFORE还是AFTER？BEFORE才能修改NEW，AFTER只能读 - 触发器是
FOR EACH ROW还是FOR EACH STATEMENT？历史存档必须用行级 - 函数里有没有漏掉
RETURN NEW或RETURN OLD？漏了会导致主表操作被静默丢弃
最常被忽略的是：触发器函数语言声明写成 LANGUAGE plpgsql，但实际用了 $$ 分隔符却没配对，导致函数创建成功但调用时报语法错误——这种问题只能靠 SELECT pg_get_functiondef(oid) 检查源码确认。
