触发器中动态SQL需用quote_ident()处理表名/字段名、quote_literal()处理字符串值；BEFORE行级触发器必须RETURN NEW才能生效；调用函数须带schema名并匹配参数类型；多表适配应结合TG_TABLE_NAME与TG_ARGV动态分支处理。
触发器函数里怎么用动态SQL拼接表名或字段名
直接在 EXECUTE 里拼字符串会出错，比如把 NEW.table_name 当成变量传进去——它根本不是字符串，而是 RECORD 类型的字段访问。必须用 quote_ident() 或 quote_literal() 包裹运行时值。
常见错误现象：ERROR: column "xxx" does not exist（字段名被当字面量解析）、syntax error at or near "$1"（参数占位符混进 SQL 字符串）。
- 表名、列名等标识符一律用
quote_ident()，例如EXECUTE format('INSERT INTO %I VALUES ($1)', table_name) USING NEW.id; - 字符串值用
quote_literal()或更安全的quote_nullable()，尤其当字段可能为 NULL 时 - 优先用
format()+USING，避免手拼 SQL；%I对应 identifier，%L对应 literal - 行级触发器中，
NEW和OLD是 RECORD，不能直接展开成字段列表，需逐个引用或用hstore(NEW)转换（需启用 hstore 扩展）
BEFORE 行级触发器中修改 NEW 值为什么没生效
因为没返回修改后的 NEW 记录。PL/pgSQL 触发器函数在 BEFORE ROW 场景下，必须显式 RETURN NEW 才能让变更落地；返回 NULL 会跳过当前行，返回其他值（如 OLD）会导致报错或未定义行为。
使用场景：插入前自动填充创建时间、标准化手机号格式、根据规则重写状态字段。
-
NEW.created_at := NOW();后必须跟RETURN NEW; - 如果逻辑判断后决定不执行原操作，返回
RETURN NULL; - 不能在
AFTER触发器里改NEW，它只读；也不能在语句级触发器里访问NEW/OLD（它们为 NULL） - 注意：修改
NEW字段类型要和目标列兼容，否则 INSERT/UPDATE 会失败
触发器里调用其他函数为什么总报“function does not exist”
不是函数不存在，而是调用时没带 schema 名，或者函数签名不匹配。PostgreSQL 在触发器上下文中默认 search_path 是 pg_catalog 和 public，如果你的函数在 utils schema 下，又没加前缀，就会找不到。
性能影响：每次触发都调用函数，若该函数含复杂查询或远程调用，会显著拖慢 DML 性能。
- 显式指定 schema，例如
SELECT utils.normalize_phone(NEW.phone); - 确认函数参数类型与传入值一致，
text和varchar一般可隐式转换，但integer和numeric不一定 - 避免在循环里反复调用同一函数；可提前计算好结果再赋值给局部变量
- 函数内部若含
PERFORM或SELECT，注意其执行计划会被缓存，重建被调函数后需CREATE OR REPLACE FUNCTION或重启会话
如何让一个触发器适配多张表而不重复写函数
做不到“完全通用”，但可通过参数化设计减少重复。核心是利用 TG_TABLE_NAME 和 TG_ARGV[] 动态获取上下文，再配合动态 SQL 分支处理。
容易踩的坑：把表名硬编码进函数体、忽略不同表字段结构差异、误以为 TG_ARGV 是全局变量（它只在当前触发器创建时传入）。
- 创建触发器时用
CREATE TRIGGER ... EXECUTE FUNCTION audit_log_func('students');，函数内用TG_ARGV[0]拿到表名 - 用
TG_TABLE_NAME获取实际触发的表名（比TG_ARGV更可靠，尤其跨继承表时） - 字段操作前先查
pg_attribute确认是否存在，或用EXISTS(SELECT 1 FROM pg_attribute WHERE attname = 'xxx' AND attrelid = TG_RELID) - 别指望靠一个函数处理 INSERT/UPDATE/DELETE 全部逻辑还保持清晰——按操作类型拆分函数更易维护
NEW/OLD 是快照，EXECUTE 是另起一轮解析。稍不注意，就变成“看起来在改数据，其实什么都没发生”。 
