SET_SESSION_AUTHORIZATION(7pg17)

💅 SET_SESSION_AUTHORIZATION (7pg17) — or, "how to swap your whole identity in SQL" 🎭

okay bestie, so this is the page for SET_SESSION_AUTHORIZATION from the PostgreSQL 17.11 docs, and honestly? it's giving main character energy but for user identities. let's get into it ✨

---

💖 NAME 💖

SET_SESSION_AUTHORIZATION — sets the session user identifier and the current user identifier of the current session. that's it, that's the whole vibe check 🫶

---

✨ SYNOPSIS ✨

SET [ SESSION | LOCAL ] SESSION AUTHORIZATION user_name
SET [ SESSION | LOCAL ] SESSION AUTHORIZATION DEFAULT
RESET SESSION AUTHORIZATION

like, three whole ways to do the thing. pick your fighter 💅

---

🌸 DESCRIPTION 🌸

so this command sets the session user identifier and the current user identifier of the current SQL session to be user_name. and listen, user_name can be written as either an identifier or a string literal — either way slays. using this command it's possible, for example, to temporarily become an unprivileged user and later switch back to being a superuser. literally identity theft but consensual and SQL-sanctioned 😭👑

the session user identifier is initially set to be the (possibly authenticated) user name provided by the client. the current user identifier is normally equal to the session user identifier, but might change temporarily in the context of SECURITY DEFINER functions and similar mechanisms — also it can be changed by SET ROLE. and the current user identifier? that's the one that's actually relevant for permission checking, so don't sleep on it 🎀

⚠️ important lore: the session user identifier can be changed only if the initial session user (the authenticated user) has the superuser privilege. otherwise, the command is accepted only if it specifies the authenticated user name. so like, no unauthorized glow-ups, bestie 💀

the SESSION and LOCAL modifiers act the same as for the regular SET command. same behavior, different context, iykyk 🦋

and the DEFAULT and RESET forms? they reset the session and current user identifiers to be the originally authenticated user name. and these forms can be executed by any user. yes queen, everybody gets to come home 🏠💖

---

🎀 NOTES 🎀

SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function. periodt. no cap. 🚫

---

🔥 EXAMPLES 🔥

okay so here's the whole glow-up in action:

SELECT SESSION_USER, CURRENT_USER;

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

SET SESSION AUTHORIZATION 'paul';

SELECT SESSION_USER, CURRENT_USER;

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

the way peter simply becomes paul 😭 iconic behavior, honestly 🌈

---

🦋 COMPATIBILITY 🦋

the SQL standard allows some other expressions to appear in place of the literal user_name, but these options are not important in practice. ngl, the standard is doing the most for no reason 🙈

• PostgreSQL allows identifier syntax ("username"), which SQL does not.
• SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. we're chill like that 💅
• the SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. extra, but make it fashion ✨

the privileges necessary to execute this command are left implementation-defined by the standard. so, like, the standard just handed it off and said "you figure it out" 💀

---

🌟 SEE ALSO 🌟

• SET ROLE (SET_ROLE(7)) — your other fave identity-shifting icon, go read it next 🫶

---

and that's the whole page, bestie! this adorable lil rewrite is brought to you by PostgreSQL 17.11, dated 2026 — same docs, same facts, way more sparkle 🎀💖✨🦋🌸