set role用于切换当前会话角色，需已显式被grant目标角色且无noinherit限制；执行后current_role变更而session_user不变；禁用时用reset role最安全；不可用default语法；与需superuser权限的set session authorization有本质区别。
启用当前会话角色：用 set role 切换到已有角色
你必须已通过 set role 被授予目标角色（即该角色是你的 member of 关系），且该角色未被 noinherit 限制。执行时直接指定角色名即可：
SET ROLE 'analyst';
注意：SET ROLE 不会继承父角色权限，只激活显式指定的角色——哪怕你有 admin 角色，也不能靠它间接获得 analyst 的权限，除非 analyst 是 admin 的成员（或你被显式 GRANT analyst TO current_user）。
- 若目标角色带密码（
LOGIN属性），SET ROLE仍无需密码——它不验证身份，只检查授权关系 - 执行后，
CURRENT_ROLE和SESSION_USER会不同：SESSION_USER保持登录用户，CURRENT_ROLE变为目标角色 - 不能
SET ROLE到一个你自己没被GRANT的角色，否则报错：permission denied to set role "xxx"
禁用临时角色：恢复为初始会话角色
回到最初连接时的默认角色（通常是登录用户本身），用以下任一方式：
RESET ROLE;
或显式切回原用户：
SET ROLE 'alice'; -- 假设登录用户是 alice
RESET ROLE 是最安全的做法，尤其在不确定当前 CURRENT_ROLE 是什么时——它总是回到会话起点，不受中间多次 SET ROLE 影响。
- 如果之前用
SET ROLE NONE，则RESET ROLE仍能正确返回初始角色；SET ROLE NONE只是清空当前角色上下文，并非“退出”会话 -
RESET ROLE不影响已打开的事务、临时表或变量设置，仅重置权限上下文 - 不要依赖
SET ROLE DEFAULT——PostgreSQL 不支持该语法，会报错syntax error at or near "DEFAULT"
为什么 SET ROLE 不生效？常见权限链断裂点
最常踩的坑不是语法错，而是权限未真正授予或被显式拒绝：
- 目标角色必须通过
GRANT role_name TO current_user显式授予，INHERIT属性不会让SET ROLE自动可用 - 若角色创建时带
NOINHERIT，不影响SET ROLE（因为SET ROLE本就不依赖继承），但若你误以为“有继承就有切换权”，就会卡住 - 超级用户可绕过大部分检查，但普通用户一旦被
REVOKE掉目标角色，SET ROLE立即失败，且不会提示“曾有过” - 连接串中若含
options=-c+role=xxx，会自动触发SET ROLE，可能掩盖手动调试过程中的预期行为
与 SET SESSION AUTHORIZATION 的关键区别
别混淆这两个命令：SET ROLE 是权限降级/切换，SET SESSION AUTHORIZATION 是身份冒充（需 superuser 权限）：
-
SET ROLE普通用户就能用，只要被授予权限；SET SESSION AUTHORIZATION必须是 superuser，且会改变SESSION_USER和CURRENT_USER -
SET SESSION AUTHORIZATION后，连RESET ROLE都无法恢复原始用户，必须断开重连或再执行一次SET SESSION AUTHORIZATION DEFAULT - 日常权限隔离场景（如应用内多租户数据访问控制）应优先用
SET ROLE，而非滥用SET SESSION AUTHORIZATION
角色切换本身不耗资源，但每次权限检查都会走新的角色上下文，若频繁切换又没配好行级策略（RLS），可能引发意外拒绝或越权——这点容易被忽略。
