如何永久锁定PostgreSQL表中已审计签核的特定行以阻止编辑？

1. 触发器拦截修改 #

这是最直接的数据库层面强制控制方式，通过触发器在修改/删除操作前检查行的审计状态，直接阻止对已完成审计数据的操作。

操作步骤：

• 给目标表添加审计状态字段（比如audit_status，可设为枚举类型，包含'pending'/'completed'两种状态）
• 创建触发器函数，检测到行的audit_status为completed时抛出异常：

CREATE OR REPLACE FUNCTION block_audited_rows()
RETURNS TRIGGER AS $$
BEGIN
  IF OLD.audit_status = 'completed' THEN
    RAISE EXCEPTION '已完成审计的数据无法修改或删除';
  END IF;
  RETURN NEW;
END;
$$ LANGUAGE plpgsql;

• 将触发器绑定到表的UPDATE和DELETE操作：

CREATE TRIGGER trigger_block_audited_rows
BEFORE UPDATE OR DELETE ON your_table
FOR EACH ROW EXECUTE FUNCTION block_audited_rows();

优点：无需调整现有业务逻辑，数据库层面强制拦截，避免应用层疏漏。
缺点：每次修改操作都会触发函数，对性能有极微小影响（通常可忽略）。

2. 拆分表物理隔离 #

把已完成审计的数据迁移到单独的只读历史表，主表仅保留未完成审计的数据，从物理层面彻底隔离可修改范围。

操作步骤：

• 创建与主表结构完全一致的历史表（比如your_table_history）
• 在审计完成时，将对应数据移到历史表并删除主表中的记录：

INSERT INTO your_table_history
SELECT * FROM your_table WHERE audit_status = 'completed';

DELETE FROM your_table WHERE audit_status = 'completed';

• 给普通用户分配主表的UPDATE/DELETE权限，仅分配历史表的SELECT权限：

GRANT SELECT, INSERT, UPDATE, DELETE ON your_table TO regular_user;
GRANT SELECT ON your_table_history TO regular_user;

优点：彻底隔离数据，性能最优，历史数据可单独归档或备份。
缺点：需要维护数据迁移逻辑，查询全量数据时需联合主表和历史表。

3. 行级权限（RLS）控制 #

利用PostgreSQL的行级安全特性，精准限制用户仅能修改未完成审计的行。

操作步骤：

• 开启目标表的RLS功能：

ALTER TABLE your_table ENABLE ROW LEVEL SECURITY;

• 创建UPDATE和DELETE策略，仅允许操作未完成审计的行：

CREATE POLICY allow_edit_unaudited ON your_table
FOR UPDATE USING (audit_status != 'completed');

CREATE POLICY allow_delete_unaudited ON your_table
FOR DELETE USING (audit_status != 'completed');

• 确保普通用户没有BYPASSRLS权限，避免绕过行级限制。
  优点：细粒度权限控制，无需触发器，性能优于触发器方案。
  缺点：仅PostgreSQL 9.5及以上版本支持，需要理解RLS的权限逻辑。

4. 应用层配合状态字段（不推荐单独使用） #

在表中添加audit_completed布尔字段，应用层所有修改/删除接口先检查该字段，若为true则直接拒绝操作。

注意：该方式仅依赖应用层控制，无法阻止用户直接通过数据库客户端修改数据，建议配合上述数据库层面的方案一起使用。

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