触发器不能实现行级安全性增强，因其不参与select过滤；rls才是唯一合规机制，它在查询重写阶段自动注入谓词，覆盖select/insert/update/delete全操作，并与会话变量无缝集成。
TRIGGER 不能实现行级安全性增强——这是根本性误用。PostgreSQL 的行级安全（RLS）才是唯一合规、可靠、全操作覆盖的机制；触发器只负责数据变更时的校验与响应，不参与查询过滤。
为什么 BEFORE UPDATE 触发器拦不住跨租户 SELECT
SELECT 不触发任何触发器，无论 BEFORE 还是 AFTER 都完全无效。你写一百个触发器，对 SELECT * FROM orders 都毫无影响。用户仍能查到全部数据，策略形同虚设。
常见错误现象：
- 应用层手动拼
WHERE tenant_id = ?，但漏写或被绕过 - 用
AFTER INSERT自动补tenant_id，却没限制SELECT可见范围 - 在
BEFORE UPDATE中RAISE EXCEPTION拒绝非法修改，但旧数据早已暴露给前端
CREATE POLICY 才是真正的行级过滤入口
RLS 策略在查询重写阶段注入谓词，天然覆盖 SELECT、INSERT、UPDATE、DELETE 全链路，且与 current_setting() 会话变量无缝集成。
关键实操步骤：
PostgreSQL 18.4 ubuntu
下载
PostgreSQL 18.4 官方 Ubuntu 安装包现已发布，这是目前最新的稳定版本。推荐通过官方 APT 仓库安装：先执行 sudo apt update 更新索引，再运行 sudo apt install postgresql-18 即可完成部署。新版本引入了异步 I/O 子系统，在顺序扫描与 VACUUM 场景下性能提升显著，同时支持 UUID v7 原生生成函数与虚拟生成列。
- 先启用 RLS：
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; - 定义读写策略：
CREATE POLICY tenant_isolation ON orders FOR ALL USING (tenant_id = current_setting('app.current_tenant', true)::uuid); - 必须加
WITH CHECK控制 INSERT/UPDATE 写入归属：CREATE POLICY insert_tenant_check ON orders FOR INSERT WITH CHECK (tenant_id = current_setting('app.current_tenant', true)::uuid); - 普通用户默认受策略约束；若需超级用户也强制执行，加：
ALTER TABLE orders FORCE ROW LEVEL SECURITY;
触发器该补什么？——仅限 RLS 无法表达的强业务规则
RLS 只做“能不能看/改”，不校验“改得对不对”。比如：
- 订单金额更新后不得超过原值 120%：
BEFORE UPDATE中比较NEW.amount和OLD.amount - 状态迁移必须符合有限状态机（如
draft → submitted → shipped），不能跳步 - 删除前检查关联资源是否已归档，否则
RAISE EXCEPTION
注意：这类逻辑必须用 BEFORE 行级触发器，返回 NULL 可跳过非法行；用 AFTER 就晚了——事务已提交，再报错会导致数据不一致。
容易被忽略的兼容性细节
PostgreSQL 16 对 RLS 和触发器没有破坏性变更，但有两处极易踩坑：
-
current_setting('app.current_tenant', true)第二个参数必须为true，否则未设变量时抛错，导致整个表不可访问 - 触发器函数中若调用
pg_backend_pid()或其他会话级函数，需确认是否在并行查询中被复制执行（PostgreSQL 16 默认禁用并行 DML 的触发器，但显式开启时行为不同） - 策略名和触发器名不要重名，否则
\d table_name输出混乱，排查困难
真正要防的不是“怎么写触发器”，而是别把 RLS 责任错压给触发器——那等于拿锤子拧螺丝，越用力越歪。
