PostgreSQL触发器函数必须声明返回TRIGGER类型且仅能RETURN NEW、OLD或NULL，否则CREATE TRIGGER报错；RETURN NULL在BEFORE中拦截操作，在AFTER中无效；OLD/NEW依TG_OP动态存在，误用致运行时错误；递归触发需避免同表DML。
PostgreSQL触发器函数必须返回TRIGGER类型，不是语法强制的“形式要求”，而是数据库内核调用协议的硬性约定——不满足就无法通过函数签名校验，CREATE TRIGGER会直接报错。
触发器函数被调用时，PG内核只认TRIGGER返回值
PostgreSQL在执行INSERT/UPDATE/DELETE时，并不是“调用一个普通函数然后忽略返回值”。它会严格检查触发器函数的返回类型是否为TRIGGER，否则拒绝绑定。这个检查发生在CREATE TRIGGER阶段，不是运行时。
-
RETURN NEW、RETURN OLD、RETURN NULL都是合法的TRIGGER类型返回值；但RETURN true、RETURN 1或漏写RETURN语句，会导致ERROR: function ... must return type trigger - 即使函数体逻辑完全正确，只要声明为
RETURNS TEXT或RETURNS VOID，CREATE TRIGGER就失败 - PL/pgSQL中
RETURN后面不能跟表达式求值结果（比如RETURN now()），只能是NEW、OLD或NULL这三个特殊值之一
RETURN NULL在BEFORE触发器中会跳过当前行操作
这不是“返回空值”的语义，而是触发器协议定义的行为信号：内核看到RETURN NULL，就理解为“请丢弃这一行的原始操作”。这常用于业务拦截场景。
- 在
BEFORE INSERT中RETURN NULL→ 该行不插入，也不报错 - 在
BEFORE UPDATE中RETURN NULL→ 该行不更新，原值保留 - 在
AFTER触发器中RETURN NULL无实际效果（建议统一写RETURN NULL保持风格一致） - 误在
BEFORE中写了RETURN NEW却没修改NEW字段，等同于放行；想拦截必须显式RETURN NULL
访问OLD或NEW前必须确认触发事件类型
OLD和NEW不是始终存在的变量，它们的可用性由触发事件决定。直接引用未定义的记录会导致运行时报错：record "old" has no field "xxx"。
-
INSERT：只有NEW有效，OLD为NULL；访问OLD.id直接崩溃 -
DELETE：只有OLD有效，NEW为NULL；访问NEW.name同样报错 -
UPDATE：两者都存在，可对比字段差异，如IF OLD.status != NEW.status THEN ... - 通用写法是先判断：
IF TG_OP = 'UPDATE' THEN ... ELSIF TG_OP = 'INSERT' THEN ...
递归触发常因RETURN NEW后又执行同表DML而发生
最典型的陷阱：在AFTER UPDATE触发器里执行UPDATE本表，再触发自身——因为AFTER已无法用RETURN NULL阻止原操作，且每次更新都会再次激活触发器，最终栈溢出。
- 修复方式是改用
BEFORE UPDATE，直接修改NEW.updated_at := NOW()，然后RETURN NEW，不发额外UPDATE语句 - 若必须执行DML（如写审计日志到另一张表），确保目标表与触发表不同，避免循环
- 极少数需自治事务的场景，不能靠触发器实现，得用
dblink异步或应用层补偿
真正容易被忽略的是：触发器函数的返回值既是类型契约，也是行为开关。它不只让函数能被创建，更直接控制数据行是否落地、何时落地、以什么状态落地——把RETURN当成普通函数的收尾，是多数人踩坑的起点。
