触发器无法可靠获取当前用户有效角色，PostgreSQL和MySQL均不支持在触发器中准确识别SET ROLE状态或RLS上下文；必须通过应用层显式传参，并配合RAISE/SIGNAL中断操作，或优先使用PostgreSQL的RLS机制。
触发器里根本拿不到当前用户的有效角色
PostgreSQL 和 MySQL 的触发器函数运行时，current_user、session_user 只返回登录用户名，不包含其所属角色或当前生效的 SET ROLE 状态。MySQL 触发器甚至禁止查系统表，连 SELECT * FROM mysql.role_edges 都直接报错；PostgreSQL 里查 pg_roles 或 pg_has_role() 也常返回空或权限拒绝——因为触发器没继承会话上下文，也不感知 RLS 是否启用。
常见错误现象：ERROR: permission denied for table pg_roles（没权限），或子查询返回空（current_role 是默认角色，不是实际操作角色）。
- 别在触发器里写
SELECT ... FROM pg_auth_members或IS_MEMBER('admin') - SQL Server 的
ORIGINAL_LOGIN() + IS_MEMBER()在触发器中大概率返回NULL，不可靠 - 真正能稳定获取“谁在删、以什么身份删”的，只有应用层显式传参，比如通过
SET LOCAL app.user_id = 'u123'（PG）或自定义连接参数（MySQL）
DELETE 触发器必须用 RAISE 中断，不能只改 OLD
OLD 是只读虚拟表，你没法给它赋值，但很多人误以为能“修正”删除条件。实际能做的只有校验失败后立刻终止操作——否则语句照常执行，权限控制形同虚设。
常见错误现象：触发器检查用户无权删某类记录，却只打印日志或设个变量，结果 DELETE FROM orders WHERE id = 123 还是成功了。
- PostgreSQL 必须用
RAISE EXCEPTION 'no delete permission' - MySQL 必须用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'xxx'；用SELECT 1或SET @msg = '...'不会中断执行 - 别在 BEFORE DELETE 触发器里试图修改
OLD.status或其他字段——OLD不可写，语法直接报错
用 RLS 替代 DELETE 触发器更可靠
PostgreSQL 的行级安全（RLS）在执行计划生成阶段就注入过滤条件，能正确识别 current_user、current_role，还能调用 pg_has_role() 做动态判定。它比触发器轻量、可审计、且不干扰事务语义。
示例：限制普通用户只能删自己提交的订单
ALTER TABLE orders ENABLE ROW LEVEL SECURITY; CREATE POLICY delete_own ON orders FOR DELETE USING ( user_id = (SELECT id FROM users WHERE username = current_user) );
-
USING控制“能否删”，WITH CHECK不用于 DELETE，不用写 - 确保
users表上对username有索引，否则每次删都全表扫描 - 避免在策略里调用复杂函数（如自定义 PL/pgSQL 函数），否则优化器可能下推失败，策略失效
MySQL 没有 RLS，只能靠应用层或存储过程兜底
MySQL 8.0+ 的“Data Masking”不是 RLS，不支持基于角色的动态行过滤；触发器又无法查权限、无法拦截 SELECT、禁止嵌套修改，强行用触发器做 DELETE 权限控制极易被绕过。
可行路径只有两条：
- 应用层拼
WHERE user_id = ? AND role IN ('admin', 'manager')，数据库只认这个条件 - 封装成存储过程，由应用调用
CALL delete_order(123, 'u123', 'editor')，过程内查权限表再执行 DELETE - 千万别把权限逻辑塞进触发器——MySQL 触发器连
SELECT USER()都可能返回代理层账号，不是真实业务用户
最易被忽略的点：哪怕你写了看似完整的触发器，只要应用直连数据库执行 DELETE FROM orders WHERE id = 123，就完全绕过所有校验。真正的权限边界不在数据库对象上，而在应用与数据库之间的协议层。
