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

PostgreSQL触发器函数必须声明 `RETURNS TRIGGER`，并且老老实实返回 `NEW`、`OLD` 或 `NULL`，否则数据库会直接甩你一脸 `function must return type trigger`。这还没完——你得用 `TG_OP` 判断当前是插入、更新还是删除，才能安全地访问 `NEW` 或 `OLD`，不然运行时报错说“record 'old' has no field xxx”时别喊冤。校验逻辑最好封装成独立的 `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` 去注册触发器——PostgreSQL 不认

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`）只对自己生效，不影响外层调用者的事务边界——这点区别，踩过坑的人自然懂。