如何在PostgreSQL 16中使用存储过程处理复杂业务逻辑

PostgreSQL触发器函数必须声明RETURNS TRIGGER并返回NEW、OLD或NULL，否则报“function must return type trigger”；需用TG_OP判断事件类型以安全访问NEW/OLD，校验逻辑应封装为FUNCTION由触发器调用，避免副作用和性能陷阱。

PostgreSQL 16 中的存储过程（PROCEDURE）适合封装带事务控制的批量操作，但不能替代函数做校验或计算；直接拿函数逻辑改个名当触发器用，必然报 function must return type trigger。

为什么 CALL my_procedure() 会失败：返回类型和调用方式不匹配

存储过程和函数是两类东西，不是换个别名就能混用的：

• PROCEDURE 必须用 CALL 调用，不能出现在 SELECT 或 WHERE 子句里
• FUNCTION 必须有返回值，用 SELECT 调用；返回 VOID 的函数其实也是函数，只是语义上“不返回有用数据”
• 触发器函数必须声明 RETURNS TRIGGER，末尾写 RETURN NEW 或 RETURN NULL；哪怕逻辑完全一样，也不能把 CREATE OR REPLACE PROCEDURE 直接当触发器注册

TG_OP 判断不到位导致 record "old" has no field "xxx"

这个错误不是语法错，是运行时报的——你写了 OLD.status，但当前是 INSERT，OLD 根本不存在。PostgreSQL 不做空值兜底，它要求你显式判断事件类型：

• INSERT：只可用 NEW，OLD 是 NULL
• DELETE：只可用 OLD，NEW 是 NULL
• UPDATE：两者都可用，但字段可能未变（比如只更新了 updated_at）
• 安全写法是 IF TG_OP = 'UPDATE' THEN ... END IF; 包裹对 OLD 的访问，别用 COALESCE(NEW.status, OLD.status) 这类表达式，除非你确认语义合理

在触发器里调用校验逻辑，怎么避免事务陷阱

触发器天然运行在原始 DML 的同一事务中，这是优势也是坑：

• 校验失败抛异常 → 整个 INSERT/UPDATE 回滚，这是你要的效果
• 但如果你在触发器里写了发 HTTP 请求、写外部日志表、调用 COPY 导出文件，这些副作用也会跟着回滚——而这通常不是你想要的
• 真正该放进去的，只有快、轻量、无副作用的校验：时间重叠检查、状态机流转、字段依赖验证
• 把这些校验抽成独立的 FUNCTION（返回 BOOLEAN 或直接 RAISE EXCEPTION），再由触发器函数用 PERFORM 调用
• 禁止在触发器函数里写 COMMIT 或 ROLLBACK —— PostgreSQL 会直接报 cannot commit while a cursor is open

最容易被忽略的是：触发器每行执行一次，如果校验函数内部用了游标或临时表，性能会随行数线性下降；而存储过程里的事务控制语句（BEGIN/COMMIT）只对自身生效，不影响外层调用者的事务边界。