触发器中无法直接获取当前用户有效角色，因PostgreSQL/MySQL触发器不继承会话ROLE状态且无权限查系统表，SQL Server的IS_MEMBER也常返回NULL；可靠方案是应用层传参或用RLS（PostgreSQL）/存储过程（MySQL）/EXECUTE AS（SQL Server）显式传递并校验身份。
触发器里不能直接获取当前用户角色
PostgreSQL 和 MySQL 的普通触发器函数无法访问会话级的用户权限上下文，current_user 或 session_user 只返回登录用户名，不包含其所属角色或被授予的 ROLE。试图在触发器中调用 pg_roles 或 information_schema.role_table_grants 查角色权限，结果是查不到当前会话的有效角色集合——因为触发器运行在表操作上下文中，不继承会话的 SET ROLE 状态，也不感知行级安全策略（RLS）是否启用。
常见错误现象：ERROR: permission denied for table pg_roles（没权限查系统表），或查到空结果（因未显式 SET ROLE，current_role 返回默认角色而非实际生效角色）。
- MySQL 触发器甚至不支持查询任何系统表，
SELECT在触发器内被完全禁止 - SQL Server 的
ORIGINAL_LOGIN()+IS_MEMBER()组合看似可行，但IS_MEMBER在触发器中常返回NULL，因上下文未绑定到调用者的会话角色状态 - 真正能稳定取到“当前操作者有效角色”的，只有应用层传参（如通过
application_name或自定义 GUC）或使用 RLS + 策略表达式
用 Row Level Security 配合策略表达式替代触发器
PostgreSQL 9.5+ 的 RLS 是更可靠、更轻量的方案：它在执行计划生成阶段就注入过滤条件，且能正确识别 current_user、current_role、session_user，还能结合 pg_has_role() 做动态判定。
示例：限制用户只能更新自己所在部门的数据
ALTER TABLE orders ENABLE ROW LEVEL SECURITY;
CREATE POLICY update_own_dept ON orders
FOR UPDATE
USING (department_id = (
SELECT dept_id FROM users WHERE username = current_user
))
WITH CHECK (department_id = (
SELECT dept_id FROM users WHERE username = current_user
));
-
USING控制“能否读/看到”，WITH CHECK控制“能否写/插入或更新成什么值”，二者都必须显式声明 - 避免在策略中调用复杂函数（如自定义 PL/pgSQL 函数），否则可能被优化器下推失败，导致策略失效
- 确保
users表有索引支撑子查询，否则每次 UPDATE 都全表扫描users
MySQL 中必须靠应用层或存储过程兜底
MySQL 8.0 虽支持 RLS（叫“Data Masking”），但仅限列级脱敏，不支持行级更新拦截；也没有触发器内权限检查能力。唯一可行路径是把 UPDATE 封装进存储过程，并强制校验调用者身份：
DELIMITER $$
CREATE PROCEDURE safe_update_order(
IN p_order_id INT,
IN p_status VARCHAR(20),
IN p_caller_username VARCHAR(64)
)
BEGIN
DECLARE v_dept_id INT;
SELECT dept_id INTO v_dept_id
FROM users WHERE username = p_caller_username;
IF v_dept_id IS NULL THEN
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Invalid caller';
END IF;
UPDATE orders
SET status = p_status
WHERE id = p_order_id AND department_id = v_dept_id;
END$$
DELIMITER ;
- 调用方必须显式传入
p_caller_username，不能依赖USER()—— 因为连接池复用时USER()返回的是连接池账号，不是真实操作人 - 存储过程无法防止绕过调用（如直连数据库执行 UPDATE），所以需配合网络层鉴权（如 ProxySQL 规则）或禁用普通用户对表的直接 DML 权限
- 性能上，每次 UPDATE 多一次
users表查询，建议加username索引
SQL Server 的 INSTEAD OF 触发器 + EXECUTE AS 是折中解
SQL Server 允许在触发器中用 EXECUTE AS CALLER 切换上下文，并调用 IS_ROLEMEMBER() 检查角色，但必须提前给触发器签名授权，否则报错 The module 'xxx' depends on the missing object 'xxx'. The module will still be created; however, it cannot run successfully。
- 先创建触发器，再用
ADD SIGNATURE绑定证书或密钥，否则IS_ROLEMEMBER总返回0 - 不能在触发器里用
CONTEXT_INFO传参——它跨批失效，UPDATE 批处理中不可靠 - 更稳的方式是让应用在 UPDATE 前先执行
SET CONTEXT_INFO，触发器里用CONVERT(VARCHAR(128), CONTEXT_INFO())解析出角色名再比对
真正难缠的点从来不是语法怎么写，而是“谁在哪个时刻以什么身份执行了什么语句”这个事实，在不同数据库的执行上下文里根本不可见——你得主动把它塞进去，而不是指望系统自动告诉你。
