能解决多表JOIN、聚合、DISTINCT、计算列等导致的视图不可插入问题，通过接管INSERT逻辑将操作重定向为自定义PL/SQL或PL/pgSQL代码，实现跨表写入、校验填充及业务逻辑嵌入。
INSTEAD OF触发器能解决哪些视图插入问题？
普通视图不支持直接 INSERT，尤其当视图涉及 JOIN、聚合、DISTINCT 或计算列时，数据库会报错 ORA-01732（Oracle）或 ERROR: cannot insert into view（PostgreSQL）。INSTEAD OF 触发器不是绕过限制，而是接管插入逻辑——它让数据库把对视图的 INSERT 操作，转为执行你定义的 PL/pgSQL 或 PL/SQL 代码块。关键前提是：该视图必须是“不可更新”的，否则触发器根本不会被调用。
常见适用场景包括：
- 多表联合视图（如
orders JOIN customers JOIN products） - 带
CASE表达式或函数计算字段的视图 - 需要校验、默认填充、或跨库写入的插入路径
PostgreSQL 中创建 INSTEAD OF INSERT 触发器的实操要点
PostgreSQL 要求目标视图必须是“无规则（no rules）”且未定义 WITH CHECK OPTION 的简单视图；触发器函数必须返回 trigger 类型，并在函数体内显式处理 NEW 记录。
典型步骤：
- 先写一个返回
trigger的函数，用NEW.column_name提取插入值 - 在函数里按业务逻辑拆分写入：比如把
customer_name插入customers表，拿到生成的id后再插入orders表 - 最后必须写
RETURN NEW（否则 PostgreSQL 报错trigger function must return trigger） - 用
CREATE TRIGGER ... INSTEAD OF INSERT ON view_name ... EXECUTE FUNCTION func_name()绑定
CREATE OR REPLACE FUNCTION insert_order_view()
RETURNS trigger AS $$
BEGIN
INSERT INTO customers (name) VALUES (NEW.customer_name)
ON CONFLICT (name) DO UPDATE SET name = EXCLUDED.name
RETURNING id INTO NEW.customer_id;
INSERT INTO orders (customer_id, amount)
VALUES (NEW.customer_id, NEW.amount);
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Oracle 中 INSTEAD OF 触发器的兼容性陷阱
Oracle 对 INSTEAD OF 触发器要求更严格：视图必须包含 ROWID 伪列（哪怕没显式 SELECT），否则触发器注册失败；且触发器体中不能直接用 :NEW.column 更新底层表——必须通过 SELECT ... INTO 显式查出对应主键，再做 DML。
容易踩的坑：
- 忘记在视图定义里加
customers.rowid AS cust_rowid，导致触发器不生效 - 误以为
:NEW可以直接用于UPDATE底层表，实际需先查 ID 再更新 - 在触发器中调用自治事务（
PRAGMA AUTONOMOUS_TRANSACTION）后忘了COMMIT，引发 ORA-06519 - Oracle 12c+ 支持复合触发器，但
INSTEAD OF仍只能是 BEFORE EACH ROW 类型
为什么不能用 AFTER 触发器替代 INSTEAD OF？
AFTER INSERT 是在视图插入**成功之后**才运行，但它无法阻止原始插入失败——而视图本身就不允许插入，所以 AFTER 根本不会触发。只有 INSTEAD OF 才是唯一能“拦截并重写”操作的机制。另外，SQL Server 的类似机制叫 INSTEAD OF 触发器，行为一致；但 MySQL 完全不支持该语法，必须改用存储过程封装插入逻辑。
最常被忽略的一点：触发器内所有 DML 都运行在同一个事务上下文中。如果视图插入需写三张表，其中第二张失败，整个事务回滚——这看似合理，但若你试图在触发器里调用外部 API 或写日志表，就得格外小心事务隔离和副作用控制。
