PostgreSQL中父表与子表同事务插入时的审计日志触发规则优化问题

这个需求太常见了——我之前帮好几个项目处理过类似的关联表审计场景，完全不用加那些让你觉得 kludgy 的额外业务字段，PostgreSQL 本身就提供了干净的解决方案！

我给你两个实操性强的思路，都是基于PostgreSQL自带的特性，不用改现有表结构：

方案一：利用系统字段xmin追踪同事务插入 #

PostgreSQL的每个表都自带xmin系统字段，它存储了插入这条记录的事务ID。我们可以在子表的触发器函数里，对比父表对应记录的xmin和当前事务ID，判断是不是同事务插入的父表：

CREATE OR REPLACE FUNCTION line_item_audit_trigger()
RETURNS TRIGGER AS $$
BEGIN
    -- 检查当前子项关联的父发票是否是在当前事务中插入的
    IF EXISTS (
        SELECT 1 
        FROM invoice
        WHERE id = NEW.invoice_id
        AND txid_current() = txid_from_xmin(xmin)
    ) THEN
        -- 同事务插入的父表，跳过子项的审计日志
        RETURN NEW;
    ELSE
        -- 非同事务插入，记录审计日志
        INSERT INTO audit_log (table_name, record_id, action, created_at)
        VALUES ('line_item', NEW.id, 'INSERT', NOW());
        RETURN NEW;
    END IF;
END;
$$ LANGUAGE plpgsql;

这里的txid_from_xmin(xmin)是把xmin转换成可直接和txid_current()对比的事务ID，完全依赖PostgreSQL的系统特性，不用加任何自定义字段。

方案二：用事务级临时变量标记父表操作 #

另一个更直观的方法是在父表的插入触发器里，设置一个事务级的本地变量，这个变量只会在当前事务内有效，事务结束后自动失效。子表的触发器只要检查这个变量是否存在，就能判断要不要跳过日志：

父表触发器函数（设置标记） #

CREATE OR REPLACE FUNCTION invoice_audit_trigger()
RETURNS TRIGGER AS $$
BEGIN
    -- 记录父发票的审计日志
    INSERT INTO audit_log (table_name, record_id, action, created_at)
    VALUES ('invoice', NEW.id, 'INSERT', NOW());
    
    -- 设置事务级本地变量，标记当前事务有新发票插入
    SET LOCAL myapp.new_invoice_created = 'true';
    RETURN NEW;
END;
$$ LANGUAGE plpgsql;

子表触发器函数（检查标记） #

CREATE OR REPLACE FUNCTION line_item_audit_trigger()
RETURNS TRIGGER AS $$
BEGIN
    -- 尝试读取事务变量，不存在则返回空（第二个参数true允许无报错）
    IF current_setting('myapp.new_invoice_created', true) = 'true' THEN
        -- 同事务有新发票插入，跳过子项日志
        RETURN NEW;
    ELSE
        -- 无标记，记录审计日志
        INSERT INTO audit_log (table_name, record_id, action, created_at)
        VALUES ('line_item', NEW.id, 'INSERT', NOW());
        RETURN NEW;
    END IF;
END;
$$ LANGUAGE plpgsql;

这个方法的好处是逻辑更清晰，你可以在变量里带更多信息（比如发票ID），后续扩展也更灵活，而且完全不会污染业务表。

注意事项 #

• 用xmin的方法要注意：如果你的父表记录在同事务中被更新过，xmin还是会保留最初插入的事务ID，所以不影响判断；另外需要确保触发器函数有足够权限读取系统字段（一般默认权限就够）。
• 事务级变量的方法要注意：变量名最好加自定义前缀（比如myapp.），避免和PostgreSQL的内置变量冲突。

这两个方案都比加额外业务字段的方法更优雅，完全利用PostgreSQL的事务和系统特性，不会给你的业务表带来冗余字段。

内容来源于stack exchange