SET_ROLE(7)

💖 SET_ROLE — the manual page, but make it make sense 💖

okay bestie, welcome to the PostgreSQL 18.6 Documentation glow-up of SET ROLE(7). this is the page that tells you how to swap who you are in a SQL session, and honestly? it's giving shapeshifter. let's go. 🦋

---

✨ NAME ✨

SET_ROLE — set the current user identifier of the current session 🎀

---

✨ SYNOPSIS ✨

SET [ SESSION | LOCAL ] ROLE role_name
SET [ SESSION | LOCAL ] ROLE NONE
RESET ROLE

---

✨ DESCRIPTION ✨

so this command sets the current user identifier of the current SQL session to be role_name. and the role name? you can write it as an identifier or as a string literal — dealer's choice, both slay. 💅

after SET ROLE, permissions checking for SQL commands is carried out as though the named role were the one that had logged in originally. like, you're cosplaying that role so hard the permission system fully believes you. main character energy ✨

not me about to drop a very important exception: SET ROLE and SET SESSION AUTHORIZATION are exceptions to the above! permissions checks for those continue to use the current session user and the initial session user (the authenticated user), respectively. so no, you can't fake your way through those ones. 🫶

the current session user must have the SET option for the specified role_name, either directly or indirectly via a chain of memberships with the SET option. (if the session user is a superuser, any role can be selected — superuser privileges are the ultimate hall pass, no cap. 👑)

the SESSION and LOCAL modifiers act the same as for the regular SET command.

now the two lil cleanup forms:

• SET ROLE NONE sets the current user identifier to the current session user identifier, as returned by session_user.
• RESET ROLE sets the current user identifier to the connection-time setting specified by the command-line options, ALTER ROLE, or ALTER DATABASE, if any such settings exist. otherwise, RESET ROLE sets the current user identifier to the current session user identifier.

and the best part? these forms can be executed by any user. literally anyone. no special pass needed. 🎀

---

✨ NOTES ✨

using this command, it is possible to either add privileges or restrict one's privileges. the duality. the range. 😭

here's the tea on how it shakes out:

• if the session user role has been granted memberships WITH INHERIT TRUE, it automatically has all the privileges of every such role. in this case, SET ROLE effectively drops all the privileges except for those which the target role directly possesses or inherits. so you're trimming the vibes down to just the target role's stuff. ✂️
• on the other hand, if the session user role has been granted memberships WITH INHERIT FALSE, the privileges of the granted roles can't be accessed by default. however, if the role was granted WITH SET TRUE, the session user can use SET ROLE to drop the privileges assigned directly to the session user and instead acquire the privileges available to the named role.
• if the role was granted WITH INHERIT FALSE, SET FALSE then the privileges of that role cannot be exercised either with or without SET ROLE. dead. blocked. no entry. 💀

SET ROLE has effects comparable to SET SESSION AUTHORIZATION, but the privilege checks involved are quite different. also, SET SESSION AUTHORIZATION determines which roles are allowable for later SET ROLE commands, whereas changing roles with SET ROLE does not change the set of roles allowed to a later SET ROLE. so SET ROLE doesn't unlock new doors for future role-swapping. iykyk. 🔥

SET ROLE does not process session variables as specified by the role's ALTER ROLE settings; this only happens during login. so don't expect the full login experience, it's just a role change bestie. 🙈

🚨 SET ROLE cannot be used within a SECURITY DEFINER function. hard no. not allowed. periodt.

---

✨ EXAMPLES ✨

okay let's watch it in action, this is so satisfying actually:

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | peter

SET ROLE 'paul';

SELECT SESSION_USER, CURRENT_USER;

 session_user | current_user
--------------+--------------
 peter        | paul

see how session_user stays peter but current_user becomes paul? the way that works is genuinely iconic. 🌸

---

✨ COMPATIBILITY ✨

PostgreSQL allows identifier syntax ("rolename"), while the SQL standard requires the role name to be written as a string literal. so postgres is the chill one here. 🧚

SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. honestly? valid. 💜

the SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. postgres really said "and i'll add more, for fun." ✨

---

✨ SEE ALSO ✨

• SET SESSION AUTHORIZATION (SET_SESSION_AUTHORIZATION(7))

---

and that's the whole page bestie, no skips, no summarising, all facts preserved 🫶

PostgreSQL 18.6 🌈 2026 — mwah, take care of your session user, she's been through a lot. 💖✨🎀