PostgreSQL 13触发器与函数选型：SaaS CMS数据库业务逻辑实现咨询

优先选AFTER语句级触发器作为核心实现，同时可以封装专用存储过程给上层业务调用，原因如下：

• 你的架构规划本身就是把所有业务逻辑收敛到数据库层，触发器是最硬的兜底规则，完全避免上层开发漏调用指定方法、或者有人直接操作数据库修改文件夹父级导致的权限不一致问题，数据一致性保障等级远高于依赖上层代码规范
• 批量移动文件夹的场景下，语句级触发器仅触发1次，你可以通过PostgreSQL的过渡表直接拿到本次所有变更的文件夹ID，递归关联子文件夹、关联文档后批量更新permissions表，性能比上层逐行调用方法高1~2个数量级
• 存储过程可以给上层提供标准化的入参、返回值封装，减少上层使用成本，触发器作为最后一道防线，二者搭配是最稳妥的方案

这个认知是错误的，你的结论成立仅限定在「触发逻辑是纯批量集合操作、不需要逐行做业务判断」的场景，二者的差异如下：

• 逻辑效果并不完全一致：行级触发器可以直接拿到每行的OLD/NEW值，逐行做过滤、判断非常方便，比如仅当文件夹的parent_id字段实际发生变更才触发权限同步，语句级触发器需要先从过渡表中过滤出符合条件的行才能继续处理，复杂逐行逻辑的开发成本远高于行级触发器
• 性能优势仅存在于批量操作场景：如果业务90%以上都是单行文件夹移动操作，二者性能差异可以忽略，甚至行级触发器因为不需要额外查过渡表，开销更低
• 你提到的INSERT INTO ... SELECT * FROM new_table的优化确实成立，但仅适合不需要逐行处理的场景。如果触发逻辑需要逐行关联其他表做校验、或者做字段级的复杂计算，行级触发器的灵活度更高，不需要硬把所有逻辑写成集合操作
• 额外注意：PostgreSQL的语句级触发器过渡表会占用内存或临时表空间，单次操作影响行数超过100万级时，语句级触发器可能出现内存占用过高、临时表IO飙升的问题，反而不如拆成小批量的行级触发稳定

内容的提问来源于stack exchange，提问作者Khaled Jamoos