过渡表，在PostgreSQL 10中引入，通过语句级别的触发器中的REFERENCING子句提供了这一能力。该机制将修改的整个结果集暴露为临时表结构——对于INSERT/UPDATE操作为NEW TABLE，对于DELETE/UPDATE操作为OLD TABLE——使触发函数能够执行基于集合的处理。您可以执行一条操作所有受影响行的单个SQL语句，而不是逐行迭代。
CREATE TRIGGER bulk_audit_trigger AFTER UPDATE ON inventory REFERENCING NEW TABLE AS updated_items OLD TABLE AS previous_items FOR EACH STATEMENT EXECUTE FUNCTION log_inventory_changes();
在log_inventory_changes()内部，查询updated_items将返回触发的UPDATE所影响的所有行，从而能够进行高效的批量操作，如INSERT INTO audit_log SELECT * FROM updated_items;。
一个电子商务平台在夜间进行大量价格调整时遭遇了严重的性能下降，影响了100,000个产品记录。现有架构使用行级AFTER触发器来写入审计条目，导致对price_history表进行100,000次顺序INSERT执行，并耗尽了连接池资源。
解决方案1：应用程序侧批量处理 团队考虑去除触发器，并通过Java应用程序使用JDBC批量插入处理审计。尽管这会减少数据库CPU负载，但引入了关键的一致性风险：如果应用程序在批处理过程中崩溃，已提交的价格更新将永久缺少相应的审计记录，违反SOX合规性。此外，这种方法还需要在应用服务器和PostgreSQL之间进行复杂的分布式事务管理。
解决方案2：异步消息队列 另一个提议涉及在更新期间将行标识符写入Redis流，然后通过后台工作程序处理审计。这解耦了写入路径，但牺牲了即时的事务一致性。异步工作程序在高负载期间可能会滞后，从而造成审计轨迹中的临时缺口，导致审计监管员标记。此外，确保PostgreSQL和Redis之间的精确一次语义增加了巨大的基础设施复杂性。
解决方案3：使用过渡表的语句级触发器
选择的方案用语句级触发器替换了行触发器，利用REFERENCING NEW TABLE AS new_prices。触发函数执行了一次基于集合的操作：INSERT INTO price_history SELECT product_id, old_price, new_price, NOW() FROM new_prices;。这在同一事务内保持了严格的ACID合规，同时一次处理所有修改。
结果： 每晚批处理完成时间从45秒减少到300毫秒。WAL（预写日志）生成减少了90%，系统消除了以前由于大规模触发递归引起的锁争用高峰。
过渡表如何与BEFORE触发器和视图上的INSTEAD OF触发器交互？
过渡表仅在普通表上的AFTER触发器中可用。BEFORE触发器在语句最终结果集物化之前对单独行进行操作，因此尚不存在修改行的完整集合。视图上的INSTEAD OF触发器无法使用过渡表，因为它们定义了替代的执行路径，而不是观察基础表上的实际DML操作结果。
触发函数可以修改NEW TABLE或OLD TABLE中的数据以更改最终结果吗？
不可以，过渡表是只读快照，仅在触发器执行期间可访问。它们表示受语句影响的行的不可变视图，无法通过UPDATE、DELETE或INSERT操作进行修改。要在提交之前更改值，您必须使用行级BEFORE触发器直接操作NEW记录变量，或对永久表执行单独的DML。
为什么TRUNCATE操作不会填充OLD TABLE过渡表？
尽管PostgreSQL支持在语句级别的TRUNCATE上使用触发器，但该DDL命令删除所有行而不生成单独的行过渡状态，通过MVCC系统。TRUNCATE绕过构建过渡关系所需的元组版本机制，因此无法将已删除的行填充到OLD TABLE中。审计TRUNCATE操作需要替代机制，例如事件触发器或逻辑解码流。