触发器函数必须返回TRIGGER类型，不能用PROCEDURE替代；须声明RETURNS TRIGGER，末尾写RETURN NEW/OLD/NULL；访问NEW或OLD前需用TG_OP判断事件类型，避免运行时报错。
触发器调用存储过程时为什么总报 function must return type trigger
因为触发器函数和普通存储过程是两类东西：触发器函数必须返回 TRIGGER 类型，而存储过程用 CALL 调用、不返回值。直接把一个 CREATE OR REPLACE PROCEDURE 当作触发器函数注册，PostgreSQL 会立刻拒绝。
常见错误是复制了校验逻辑的存储过程代码，只改了函数名和 LANGUAGE，却忘了改返回类型和末尾 RETURN 语句。
- 触发器函数定义开头必须是
RETURNS TRIGGER，不能是VOID或省略 - 函数体末尾必须有
RETURN NEW（INSERT/UPDATE）、RETURN OLD（DELETE）或RETURN NULL（拒绝操作） - 想复用已有校验逻辑？把它封装成独立的
FUNCTION（返回BOOLEAN或抛错），再由触发器函数调用
NEW 和 OLD 在触发器中访问字段时报 record "old" has no field "xxx"
这个错误不是语法错，是运行时错——说明你写了 OLD.field_name，但当前触发事件是 INSERT，OLD 根本不存在。
PostgreSQL 不做隐式空值保护，它要求你明确区分事件类型。哪怕只是读一个字段，也得先确认该记录变量是否可用。
-
INSERT：只有NEW可用，OLD是NULL -
DELETE：只有OLD可用，NEW是NULL -
UPDATE：两者都可用，但字段值可能相同（比如未修改的列） - 安全写法是用
IF TG_OP = 'UPDATE' THEN ... END IF;包裹对OLD的访问 - 避免写
COALESCE(NEW.status, OLD.status)这类表达式，除非你确认语义上“新增时取默认值”合理
如何让触发器调用校验逻辑又不破坏事务一致性
触发器函数天然运行在原始 DML 的同一事务中，这是优势也是陷阱：一旦校验失败抛出异常，整个 INSERT/UPDATE 就回滚；但如果你在触发器里误调用了带副作用的函数（比如发 HTTP 请求、写外部日志表），它也会跟着回滚——而这往往不是你想要的。
真正的约束校验应该快、轻量、无副作用；耗时或跨系统操作必须剥离出去。
- 校验类逻辑（如时间重叠检查、状态机流转）必须放在触发器内，用
PERFORM调用纯FUNCTION实现 - 禁止在触发器函数中写
COMMIT或ROLLBACK—— PostgreSQL 会直接报错cannot commit while a cursor is open - 需要异步通知？用
pg_notify()发消息，由外部监听进程处理；不要在触发器里COPY到文件或调用curl - 如果校验函数内部用了游标或临时表，注意
FOR EACH ROW触发器下每行都会执行一遍，性能会线性下降
重叠时间校验这类业务约束为什么不能用 CHECK 约束实现
因为 CHECK 约束只能引用当前行字段，无法查表。你想禁止「同一车牌在某天被租两次」，就得查 car_rentals 表里有没有其他行满足 plate = NEW.plate AND (start_date, end_date) OVERLAPS (NEW.start_date, NEW.end_date) —— 这个查询跨行、跨记录，CHECK 做不到。
唯一可行路径是触发器 + 函数组合：触发器捕获变更，函数执行带 SELECT 的校验，并用 RAISE EXCEPTION 中断非法操作。
- 函数里用
EXISTS (SELECT 1 FROM car_rentals WHERE ...)比SELECT COUNT(*)更高效 - 务必给
plate、start_date、end_date加联合索引，否则每次插入都要全表扫 - 测试时别只测单条插入，一定要测
UPDATE修改日期后是否仍能正确拦截重叠
SELECT 无法保证串行化——这时得配合 SERIALIZABLE 隔离级别或应用层加锁。 
