不能直接用 DROP TRIGGER + CREATE TRIGGER 覆盖重建——若原触发器正被事务持有锁或处于无效状态，会报错或静默失败；必须先查清状态、清理残留、再重建。
不能直接用 DROP TRIGGER + CREATE TRIGGER 覆盖重建——若原触发器正被事务持有锁或处于无效状态，会报错或静默失败。必须先查清状态、清理残留、再重建。
怎么判断触发器是否真的“故障”而不是只是没生效
常见错误现象不是“找不到触发器”，而是 INSERT/UPDATE 后预期逻辑没发生，比如时间字段没自动填充、日志表没写入。先确认三点：
- 用
SELECT tgname, tgenabled, tgtype, tgdeferrable FROM pg_trigger WHERE tgrelid = 'your_table'::regclass;查触发器是否存在且tgenabled为O（启用）或A（始终启用） - 检查关联的函数是否有效：
SELECT proname, prosrc FROM pg_proc WHERE oid = (SELECT tgfoid FROM pg_trigger WHERE tgname = 'your_trigger');，确保prosrc不为空且语法合法 - 执行
SELECT * FROM pg_event_trigger WHERE evtname = 'your_trigger';（仅限事件触发器），普通 DML 触发器不在此表中
重建前必须清理的三个残留点
PostgreSQL 不允许同名触发器共存，但异常中断可能导致元数据残留。手动清理比依赖 OR REPLACE 更可靠：
- 删触发器本身：
DROP TRIGGER IF EXISTS your_trigger ON your_table;—— 注意：不加IF EXISTS在触发器不存在时会报错中断后续操作 - 删函数（如果确定旧函数已损坏）：
DROP FUNCTION IF EXISTS your_trigger_func();—— 必须带括号，否则报错 - 检查并删残留的系统记录：
DELETE FROM pg_depend WHERE objid IN (SELECT oid FROM pg_trigger WHERE tgname = 'your_trigger');（极少需要，仅当DROP TRIGGER报 “object is still referenced” 时才执行）
重建语句必须带完整约束和权限上下文
直接复制旧语句重建容易漏掉关键修饰符，导致行为不一致：
- 显式指定
BEFORE/AFTER和FOR EACH ROW—— PostgreSQL 14 默认不推断粒度，缺省即为语句级，而多数业务逻辑需要行级 - 若原触发器有
WHEN (condition)，重建时必须原样保留，否则条件逻辑丢失；WHEN中不能引用NEW/OLD以外的变量 - 函数调用必须用
EXECUTE FUNCTION（14+ 推荐）而非过时的EXECUTE PROCEDURE；参数列表要与函数定义严格匹配，包括空括号() - 重建后立即验证：
INSERT INTO your_table (...) VALUES (...);后查日志表或目标字段，不要只看 SQL 是否执行成功
安全重建的最小可行脚本模板
把以下内容粘贴进 psql，替换 your_table、your_trigger、your_func 即可运行（注意末尾分号）：
DO $$
BEGIN
DROP TRIGGER IF EXISTS your_trigger ON your_table;
DROP FUNCTION IF EXISTS your_func();
CREATE OR REPLACE FUNCTION your_func() RETURNS TRIGGER AS $f$
BEGIN
NEW.updated_at := NOW();
RETURN NEW;
END;
$f$ LANGUAGE plpgsql;
CREATE TRIGGER your_trigger BEFORE UPDATE ON your_table
FOR EACH ROW EXECUTE FUNCTION your_func();
END $$;
重点：整个过程包在 DO $$ ... $$ 块里，避免部分失败导致状态不一致；函数定义和触发器创建放在同一事务内，不会出现“函数存在但触发器未绑定”的中间态。
最易被忽略的是：触发器函数里修改 NEW 后，BEFORE 行级触发器必须 RETURN NEW，少这一行，所有赋值都白做。
