不能，CREATE RULE 不能安全可靠实现条件 UPDATE，本质是查询重写而非逻辑控制；应优先用 CASE 表达式，复杂逻辑用 BEFORE 触发器。
PostgreSQL的RULE系统能替代条件UPDATE吗？不能，慎用
直接说结论：CREATE RULE 不能安全、可靠地实现“条件触发式 UPDATE”，它本质是查询重写机制，不是逻辑控制工具。很多用户想用 RULE 实现“当某字段为 X 时才更新 Y”，结果发现行为反直觉——比如 UPDATE 被静默忽略、触发多次、或绕过约束和索引。真正该用的是 BEFORE UPDATE 触发器，或更简单的 CASE 表达式内联条件。
为什么RULE在UPDATE场景下容易出错？
RULE 在执行前重写整个查询树，不检查行级条件，也不保证原子性。常见陷阱包括：
-
INSTEAD OFRULE 作用于视图时，若底层表有ON UPDATE触发器，可能被跳过 - 对同一张表定义多个 RULE，PostgreSQL 按字母序应用，顺序不可控
- RULE 无法访问
OLD或NEW行变量，没法做“仅当 old.status = 'pending' 才更新 created_at”这类判断 - 使用
DO INSTEAD时，原UPDATE的 WHERE 条件可能被丢弃，导致误更新整张表
正确做法：用CASE表达式做行内条件更新
绝大多数“条件更新”需求，一行 CASE 就能解决，性能好、语义清晰、无副作用：
UPDATE orders
SET status = CASE WHEN status = 'draft' THEN 'submitted' ELSE status END,
updated_at = CASE WHEN status = 'draft' THEN NOW() ELSE updated_at END
WHERE id = 123;
关键点：
- WHERE 子句先过滤目标行，
CASE再做行内分支，避免全表扫描 - 每个字段独立判断，不需要所有字段都参与条件逻辑
- 不会触发额外触发器（除非你显式定义了），也完全兼容事务和约束
真需要动态逻辑？用BEFORE触发器，别碰RULE
只有当逻辑涉及跨表校验、调用函数、或需中断操作（如 RAISE EXCEPTION）时，才考虑触发器：
CREATE OR REPLACE FUNCTION check_update_condition()
RETURNS TRIGGER AS $$
BEGIN
IF OLD.status = 'shipped' AND NEW.status != 'shipped' THEN
RAISE EXCEPTION 'Cannot change status from shipped';
END IF;
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
CREATE TRIGGER prevent_status_downgrade
BEFORE UPDATE ON orders
FOR EACH ROW
EXECUTE FUNCTION check_update_condition();
注意：
- 必须用
BEFORE UPDATE，不是AFTER—— 后者改完了才检查，没意义 -
RETURN NEW是必须的，否则更新会被取消；返回NULL则整行跳过 - RULE 已被官方文档标记为“legacy”，新项目应避免，尤其不要用于 DML 重写
复杂点在于：触发器逻辑会随行数线性执行，大量数据批量更新时要注意函数开销；而 RULE 看似“一次定义”，实则隐藏了不可见的查询膨胀风险——这点最容易被忽略。
