PostgreSQL在CREATE TRIGGER时立即校验函数返回类型必须为TRIGGER，否则报错；RETURN NEW/OLD/NULL是向内核发送控制信号，非普通返回值；存储过程不可替代触发器函数，因调用机制与返回类型要求不同。
因为PostgreSQL内核在绑定触发器时，会严格校验函数签名——RETURNS TRIGGER不是可选约定，而是硬性协议；不满足就直接报错，根本不会等到运行时。
CREATE TRIGGER 为什么会立刻失败？
PostgreSQL在执行 CREATE TRIGGER 语句时，并非只检查函数是否存在，而是调用系统目录比对函数的返回类型。只要函数声明为 RETURNS VOID、RETURNS TEXT 或干脆没写返回类型，就会立即报错：
ERROR: function my_func() does not exist HINT: Function must return type trigger
这个错误发生在DDL阶段，和函数体逻辑是否正确完全无关。常见诱因包括：
- 复制了存储过程代码，只改了
CREATE OR REPLACE PROCEDURE为FUNCTION，但漏掉RETURNS TRIGGER - PL/pgSQL函数里写了
RETURN true或RETURN now()这类表达式求值 - 函数末尾漏写
RETURN语句（PL/pgSQL默认返回 NULL，但类型不匹配）
RETURN NEW / OLD / NULL 到底在干什么？
这三个值不是“返回数据”，而是向内核发送控制信号：
-
RETURN NEW：仅对 INSERT/UPDATE 有效，表示“用这个新行继续操作”（BEFORE 中可修改NEW字段） -
RETURN OLD：仅对 DELETE/UPDATE 有效，表示“该行已确认删除/变更” -
RETURN NULL：在 BEFORE 触发器中 = “丢弃当前行操作”，不报错也不写入；在 AFTER 中无实际效果
误写成 RETURN 'blocked' 或 RETURN 0 会导致类型校验失败；更隐蔽的坑是：在 TG_OP = 'DELETE' 时访问 NEW，或在 TG_OP = 'INSERT' 时读 OLD，会触发运行时报错 record "old" is not assigned。
为什么不能用存储过程替代触发器函数？
因为 CALL 和 SELECT 调用机制完全不同：
- 存储过程用
CALL proc_name()执行，无返回值，不能被CREATE TRIGGER引用 - 触发器函数必须通过
SELECT func_name()形式被内核调用，且必须返回TRIGGER类型值 - 即使把校验逻辑全搬进存储过程，也得额外封装一层
RETURNS TRIGGER函数来调用它
强行混用只会卡在 function must return type trigger 这一行，毫无商量余地。
真正容易被忽略的是：触发器函数没有参数，但内核会在运行时注入 TG_OP、NEW、OLD 等魔法变量——它们的存在与否取决于事件类型，而不是函数定义。写之前不查 TG_OP 就直接读 NEW.id，上线后第一条 UPDATE 就崩。
