PostgreSQL触发器非CHECK约束增强版而是兜底机制，可跨行跨表校验但易错难调；函数须声明RETURNS TRIGGER、按TG_OP分支处理、末尾RETURN NEW/OLD/NULL；慎用COUNT(*)，优先外键+唯一索引或生成列。
PostgreSQL 的触发器不是 CHECK 约束的增强版，而是绕过其限制的兜底机制——它能做跨行、跨表、聚合计算类校验，但代价是易出错、难调试、性能敏感。真要上触发器，得先确认：这个约束真的不能用外键+唯一索引/物化视图/应用层事务解决？
触发器函数必须返回 TRIGGER 类型，且末尾要有 RETURN 语句
常见错误是把一个已有的校验 FUNCTION（比如返回 BOOLEAN）直接当触发器函数注册，结果 PostgreSQL 报错 function must return type trigger。这不是语法问题，是类型契约不匹配。
正确写法必须包含三要素：
-
RETURNS TRIGGER声明在函数定义开头 - 函数体中根据操作类型显式处理：
IF TG_OP = 'INSERT' THEN ... END IF; - 末尾必须有
RETURN NEW（INSERT/UPDATE）、RETURN OLD（DELETE）或RETURN NULL（拒绝执行）
示例片段：
CREATE OR REPLACE FUNCTION check_order_amount()
RETURNS TRIGGER AS $$
BEGIN
IF TG_OP = 'INSERT' THEN
IF NEW.amount <= (SELECT COALESCE(SUM(amount), 0) FROM orders WHERE user_id = NEW.user_id) THEN
RAISE EXCEPTION '用户累计订单金额不能低于新订单金额';
END IF;
ELSIF TG_OP = 'UPDATE' THEN
-- 这里必须同时检查 OLD 和 NEW：status 从 active → deleted 是否合法？
IF OLD.status = 'active' AND NEW.status = 'deleted' THEN
IF EXISTS (SELECT 1 FROM order_items WHERE order_id = OLD.id) THEN
RAISE EXCEPTION '删除订单前需清空关联明细';
END IF;
END IF;
END IF;
RETURN NEW; -- 注意：UPDATE 和 INSERT 都返回 NEW
END;
$$ LANGUAGE plpgsql;NEW 和 OLD 不是永远可用，访问前必须判断 TG_OP
运行时报错 record "old" has no field "xxx" 很典型——你写了 OLD.status，但触发事件是 INSERT，此时 OLD 根本不存在。PostgreSQL 不做隐式保护，也不会给你默认值。
安全写法只有两种：
- 用
IF TG_OP = 'UPDATE' THEN ... END IF;包裹所有对OLD的访问 - 绝不用
COALESCE(NEW.status, OLD.status)这类表达式，除非你明确知道“新增时取旧值”在业务上成立
记住：INSERT → 只有 NEW；DELETE → 只有 OLD；UPDATE → 两者都有，但未修改字段值相同，不能靠值相等反推“没改”。
AFTER 触发器无法阻止插入，应优先用 BEFORE + RETURN NULL
很多人用 AFTER INSERT 做校验，再 RAISE EXCEPTION 回滚——逻辑没错，但数据已落盘，哪怕回滚也会产生 WAL 日志、触发索引更新、占用 buffer cache。更糟的是，如果校验函数里误调了 PERFORM some_side_effect_function()，副作用也跟着回滚了（比如发通知失败却没重试机会）。
真正轻量、可控的做法是：
- 用
BEFORE INSERT OR UPDATE，在校验失败时直接RETURN NULL（拒绝操作），不写入任何数据 - 校验逻辑本身必须是纯函数：无
INSERT/UPDATE/DELETE、无pg_notify()、无外部 HTTP 调用 - 耗时操作（如查另一张大表、调用外部 API）必须剥离到应用层或异步监听进程，用
pg_notify()发消息即可
别在触发器里写 COMMIT 或 ROLLBACK——PostgreSQL 会立刻报错 cannot commit while a cursor is open。
跨表唯一性校验极易锁表，必须用 EXISTS + SELECT FOR UPDATE 谨慎处理
UNIQUE 约束天生不支持跨表，但硬要用触发器实现（比如 orders.email 必须不在 users.email 中重复），COUNT(*) > 0 是性能杀手，还可能引发死锁。
正确姿势：
- 用
EXISTS (SELECT 1 FROM users WHERE email = NEW.email)替代COUNT(*) - 若涉及多步校验（比如“同一 tenant 下 email 唯一”），且并发高，需在触发器函数中加
SELECT ... FROM users WHERE tenant_id = NEW.tenant_id AND email = NEW.email FOR UPDATE，但要注意锁粒度和顺序，避免循环等待 - 更推荐方案：把
users.email设为UNIQUE，orders表加外键指向它；或用 PostgreSQL 16 的生成列 + 唯一索引（ALTER TABLE orders ADD COLUMN email_lower TEXT GENERATED ALWAYS AS (LOWER(email)) STORED）
触发器只是最后防线，不是设计起点。复杂约束一旦开始依赖触发器，就说明表结构或业务模型该重新评估了。
