PostgreSQL中Rule与Trigger的差异、适用场景及Rule优势说明

二者本质不在同一个执行层生效，核心差异可以通过极简示例快速理解。

核心区别 #

先建两张测试表做演示：

CREATE TABLE users (
    id int primary key,
    username text not null
);
CREATE TABLE user_del_log (
    del_id int,
    del_username text,
    del_at timestamptz default now()
);

• 生效阶段完全不同
  • RULE 是查询重写层的机制：在SQL解析完成、生成执行计划之前就会生效，会直接把你提交的原始SQL改写成其他SQL，再进入执行流程。
    比如给users表加如下删除规则：

    CREATE RULE rule_log_user_del AS ON DELETE TO users
    DO INSTEAD (
        INSERT INTO user_del_log(del_id, del_username) VALUES (OLD.id, OLD.username)
    );
    

    此时你执行DELETE FROM users WHERE id = 1;，用EXPLAIN看执行计划会发现，根本没有对users表的删除操作，整条语句被直接替换成了往日志表插数据的逻辑——你写的原DELETE语句压根不会执行。
  • Trigger 是执行期触发机制：在DML语句真正执行的阶段才会触发，根据你定义的时机（BEFORE/AFTER/INSTEAD OF）、粒度（行级/语句级），调用独立编写的触发器函数。
    比如给users表加行级AFTER DELETE触发器记日志，流程是：先执行原DELETE语句匹配要删的行，每删一行就调用一次触发器函数，拿到当前行的OLD值写日志，原删除操作本身不会被替换。
• 操作粒度不同
  RULE 是集合级的逻辑：比如你执行DELETE FROM users WHERE id < 100;，RULE里引用OLD/NEW生成的是批量集合操作，不会逐行循环处理；行级Trigger是逐行触发，匹配到多少行就调用多少次触发器函数。
• 逻辑灵活度不同
  Trigger 的触发器函数可以用PL/pgSQL等过程化语言编写，支持循环、条件分支、异常抛出、调用其他存储过程，能实现非常复杂的业务逻辑；RULE 只能写标准SQL语句，不支持过程化逻辑。

适用场景 #

• 优先用 Trigger 的场景
  • 需要逐行做复杂校验、数据转换的逻辑：比如插入订单时根据用户等级算折扣、写入时做跨表复杂校验抛错。
  • 需要精确控制触发时机的场景：比如插入行前修改字段默认值、删除后更新统计表的聚合值。
  • 逻辑调试复杂度高的场景：触发器函数可以单独调试，执行逻辑直观，不会出现隐式改写SQL带来的预期外问题。
• 优先用 RULE 的场景
  • 给不可自动更新的视图实现DML支持：这是RULE最经典的使用场景，PostgreSQL原生的可更新视图底层就是靠RULE实现重写，把对视图的操作转发到底层基表。
  • 需要做简单的语句级操作替换/追加，且逻辑可以用标准SQL表达的场景。

RULE 的独有优势 #

• 批量操作性能更高：因为RULE直接在重写阶段生成集合级的执行计划，没有逐行调用函数的开销，批量写入、更新场景下，比行级触发器性能高很多。
• 支持全局替换原语句逻辑：比如需要限制某类角色不能真的删除用户表数据，只能留存删除操作日志，用DO INSTEAD类型的RULE可以直接把DELETE语句全局替换成插日志的逻辑，这一点Trigger做不到——哪怕是BEFORE触发器，也只能逐行跳过操作，无法直接替换整条语句的执行逻辑。
• 视图DML实现更轻量：不需要编写额外的触发器函数，靠重写规则就能实现视图到基表的操作映射，对上层业务完全透明，不需要修改原有业务SQL。

注意：不要用RULE实现复杂业务逻辑，规则嵌套很容易生成预期外的执行计划，复杂逻辑优先用Trigger，可维护性高很多。

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