postgresql触发器函数中不能直接拼接表名执行insert，必须用execute配合format()安全构造动态sql，并设为security definer，目标表须预先存在且授予权限。
触发器函数里不能直接拼接表名执行 INSERT
PostgreSQL 的触发器函数（TRIGGER FUNCTION）运行在 SQL 层，但 INSERT INTO table_name 中的 table_name 必须是静态标识符，不能是变量。直接写 EXECUTE 'INSERT INTO ' || NEW.target_table || ' ...' 会报错：ERROR: relation "xxx" does not exist（除非该表已存在且名字被解析为当前搜索路径下的有效对象），更常见的是权限或解析失败——因为动态表名必须用 EXECUTE + format() 显式构造，并且调用者需有目标表的 INSERT 权限。
实操建议：
- 触发器函数必须声明为
SECURITY DEFINER（否则执行时按调用者权限检查，很可能无权写入目标表） - 务必用
format('INSERT INTO %I.%I ...', schema_name, table_name)而非字符串拼接，防止 SQL 注入和大小写/特殊字符问题 - 目标表必须**预先存在**；触发器不负责建表，也不应承担 DDL 职责
- 若需跨 schema 写入，
format()中显式传入 schema 名，避免依赖search_path
用 BEFORE INSERT 触发器重定向行到不同表
典型场景：一个“路由表”接收原始数据，字段含 target_schema、target_table、payload_jsonb，希望根据这些字段把 payload_jsonb 解析后插入对应目标表。这时不能在 BEFORE INSERT 中修改 NEW 指向另一张表——NEW 只影响当前语句的目标表。必须改用 AFTER INSERT + 异步或显式 EXECUTE 插入。
实操建议：
-
BEFORE INSERT仅适合校验、修改本行字段（如填充默认值、转换格式），不适合跨表写入 - 真正路由写入得用
AFTER INSERT触发器，配合EXECUTE format(...) - 注意事务一致性：目标表插入失败会导致整个事务回滚，除非你主动用
BEGIN ... EXCEPTION捕获并忽略错误（不推荐） - 如果路由逻辑复杂（比如要查配置表决定目标），在触发器里做
SELECT是允许的，但别让查询变慢，否则拖累主表写入性能
动态插入时如何安全传递字段值
用 EXECUTE ... USING 传参比把值拼进 SQL 字符串更安全，但 USING 只支持标量值，不能直接传 NEW.* 或记录类型。常见错误是写 EXECUTE 'INSERT INTO t VALUES ($1)' USING NEW —— 这会报错：ERROR: column "new" does not exist。
实操建议：
- 逐字段列出要插入的列，并用
USING NEW.col1, NEW.col2, ...传参 - 若字段多且固定，可提前在触发器函数里用
hstore(NEW.*)或to_jsonb(NEW)转成 JSONB，再在目标表侧用jsonb_populate_record()解包（适合目标表结构与源表一致） - 避免用
SELECT * FROM jsonb_to_record(NEW.payload_jsonb) AS x(...)动态解构——这要求字段名、类型完全匹配，且无法利用USING参数绑定，容易出错 - 目标表字段名若与
NEW不同，必须在INSERT语句中显式映射，不能指望自动对齐
权限和性能容易被忽略的关键点
很多人测试时用 postgres 用户跑通就上线，结果生产环境普通应用用户写入时报 permission denied。根本原因是触发器函数虽设了 SECURITY DEFINER，但函数所有者对目标表没有 INSERT 权限，或者目标表在另一个 schema 里而函数所有者没被授 USAGE 权限。
实操建议：
- 给触发器函数所有者（通常是 DBA 创建的专用角色）授予所有可能目标表的
INSERT权限，以及对应 schema 的USAGE - 监控触发器执行耗时：在函数开头加
RAISE NOTICE 'route to %', target_table;并开启log_min_duration_statement = 100，观察是否因动态 SQL 编译开销大导致延迟突增 - 不要在高并发写入场景下依赖单触发器做复杂路由；考虑用应用层分表或分区表替代
- 测试时务必用真实应用用户连接，而非超级用户，否则权限问题会漏掉
动态表路由本质是把部分数据分发逻辑从应用下沉到数据库，但代价是调试困难、执行计划不可见、权限链路变长——每个目标表都得单独维护权限，每个新表都要确认触发器能否识别它。
