SET_SESSION_AUTHORIZATION(7pg18)

✨ SET_SESSION_AUTHORIZATION ✨

okay bestie so this is the PostgreSQL 18.6 Documentation page for SET_SESSION_AUTHORIZATION — it's literally the command that sets the session user identifier and the current user identifier of the current session. two identifiers, one glow-up. 💅

---

🌸 NAME 🌸

SET_SESSION_AUTHORIZATION — set the session user identifier and the current user identifier of the current session 🫶

---

🎀 SYNOPSIS 🎀

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

---

💖 DESCRIPTION 💖

So this command sets the session user identifier and the current user identifier of the current SQL session to be user_name. and like, the user name can be written as either an identifier or a string literal — both are valid, pick your fighter. ✨

Using this command, it's possible to, for example, temporarily become an unprivileged user and later switch back to being a superuser. it's giving "main character for a sec, then back to admin mode." 👑

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 it might change temporarily in the context of SECURITY DEFINER functions and similar mechanisms — and it can also be changed by SET ROLE. the current user identifier is the one that's relevant for permission checking, so like, that's the one holding the clipboard at the door. 📋

here's the big rule though, no cap: 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 if you're not a superuser, you can only be yourself. iconic but also, like, restrictive. 💀

The SESSION and LOCAL modifiers act the same as for the regular SET command. same vibe, different command. 🦋

The DEFAULT and RESET forms reset the session and current user identifiers to be the originally authenticated user name. and good news bestie — these forms can be executed by any user. so everyone gets to come home. 🏠💜

---

🧚 NOTES 🧚

SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function. that's it, that's the note. not allowed, don't try it. 🚫

---

🌈 EXAMPLES 🌈

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

look at peter becoming paul. a transformation arc. 💫

---

⭐ 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. fr fr, nobody's using them. 🙈

PostgreSQL allows identifier syntax ("username"), which SQL does not. so we're being a little extra, but in a good way. ✨

SQL does not allow this command during a transaction; PostgreSQL does not make this restriction because there is no reason to. we simply saw no reason and moved on. 💅

The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. yes, we added those. you're welcome. 🫶

The privileges necessary to execute this command are left implementation-defined by the standard. so the standard just… didn't decide. wild. 😭

---

👑 SEE ALSO 👑

SET ROLE (SET_ROLE(7))

---

that's the whole page, bestie — go forth and switch identities responsibly. and yeah, this was PostgreSQL 18.6, dated 2026. mwah. 💖🎀🦋🌸✨