PostgreSQL禁止在触发器中对被触发表执行DML，包括AFTER/BEFORE UPDATE中的UPDATE tree，报错“cannot modify table 'tree' within its own trigger function”，属内核级硬限制；可行替代方案为：①存储过程封装+临时表中转更新；②物化视图+定期刷新；③应用层接管路径维护并批量更新。
不能直接在触发器里递归更新同一张树表，这是 PostgreSQL 的硬限制，不是写法或权限问题。
为什么 AFTER UPDATE 触发器里 UPDATE tree 会报错
PostgreSQL 不允许在触发器中对被触发的表执行 DML（INSERT/UPDATE/DELETE），否则报 ERROR: cannot modify table "tree" within its own trigger function。这不是锁或事务隔离导致的临时现象，而是内核级禁止——哪怕你用 WITH RECURSIVE 查出子节点 ID，再 JOIN 更新，只要目标表是 tree，就会失败。
- BEFORE UPDATE 也不行：此时
OLD.path还没变，NEW.path又不能用于匹配后代，逻辑断层 - 语句级触发器（
FOR EACH STATEMENT）同样受限，和行级无关 - 想绕过？别试
EXECUTE 'UPDATE...'动态 SQL——照样被拦截
真正能落地的三种替代方案
必须把“路径更新”这个动作从触发器体内移出去，只留调度逻辑：
-
用存储过程封装递归更新：触发器只调用
CALL update_tree_path(OLD.id, NEW.parent_id)；该过程内部用临时表暂存待更新 ID（CREATE TEMP TABLE tmp_subtree AS SELECT id FROM tree WHERE path ~ CONCAT(OLD.path, '.*')），再UPDATE tree SET path = ... FROM tmp_subtree -
改用物化视图 + 定期刷新：建
MATERIALIZED VIEW mv_tree_with_path，里面用WITH RECURSIVE计算完整路径；业务接受秒级延迟时，用REFRESH MATERIALIZED VIEW CONCURRENTLY避免锁表 -
应用层接管路径维护：触发器只发通知（如
NOTIFY tree_update, '{"node_id": 123}'），由监听服务查出子树、拼新路径、批量更新——可控性最高，也最易调试
path 字段爆长和 NULL 处理这两个坑最容易漏
就算绕过了更新限制，path 字段长度不足或忽略 NULL 值仍会导致静默失败：
-
path别用VARCHAR(255)：ID 是 bigint、深度超 8 层时极易溢出；建表直接上VARCHAR(512)或TEXT（PG 8.0+ 支持TEXT列加前缀索引） - 触发器函数里必须显式判断：
IF NEW.parent_id IS NOT NULL THEN ...，否则CONCAT(OLD.path, '/', NEW.parent_id)产出NULL，整条 UPDATE 被跳过 - 别信默认截断：开
SET SESSION sql_mode = 'STRICT_TRANS_TABLES'，让超长直接报错，而不是悄悄丢字符
递归路径维护本质是“写时计算”，而 PostgreSQL 触发器只负责“响应写”，不负责“重写自身”。把计算逻辑推给存储过程、物化视图或应用层，才是稳定上线的分界线。
