SET_SESSION_AUTHORIZATION(7pg16)

💅 SET_SESSION_AUTHORIZATION — bestie edition ✨

okay so real talk, this is SET_SESSION_AUTHORIZATION from the PostgreSQL 16.15 Documentation — yes the whole manual page, and no I'm not skipping anything, we're doing this properly 🫶

---

🎀 NAME

SET_SESSION_AUTHORIZATION — sets the session user identifier and the current user identifier of the current session. both of them. at once. slay 💅

---

✨ SYNOPSIS

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

that's it, that's the whole vibe check 🌸

---

💖 DESCRIPTION

So this command sets the session user identifier and the current user identifier of your current SQL session to be user_name. and here's the cute part: the user name can be written as either an identifier or a string literal. either one, your choice, main character energy 👑

Using this, it's literally possible — for example — to temporarily become an unprivileged user and then later switch back to being a superuser. swap the fit, swap it back. iconic 🦋

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; it can also be changed by SET ROLE. The current user identifier is the one that's relevant for permission checking. iykyk 🔥

The session user identifier can be changed only if the initial session user (the authenticated user) had the superuser privilege. otherwise? the command is accepted only if it specifies the authenticated user name. no sneaky upgrades, bestie 🙈

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

The DEFAULT and RESET forms reset the session and current user identifiers to be the originally authenticated user name. and the good news: these forms can be executed by any user. everyone eats 🍓

---

⭐ NOTES

SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function. like, at all. not me finding this out the hard way 😭

---

🌈 EXAMPLES

first, a little vibe check on who we even are:

SELECT SESSION_USER, CURRENT_USER;

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

then we switch it up:

SET SESSION AUTHORIZATION 'paul';

and check again:

SELECT SESSION_USER, CURRENT_USER;

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

peter ➡️ paul. the transformation. we love to see it 💜

---

👑 COMPATIBILITY

The SQL standard allows some other expressions to appear in place of the literal user_name, but honestly those options are not important in practice. lowkey irrelevant 🧚

PostgreSQL allows identifier syntax ("username"), which SQL does not. and SQL does not allow this command during a transaction — PostgreSQL does not make this restriction because there is no reason to. we're built different, periodt 💀

The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. extensions on extensions on extensions ✨

Also, the privileges necessary to execute this command are left implementation-defined by the standard. so, like, it's giving "you figure it out" 🤷‍♀️

---

🦋 SEE ALSO

• SET ROLE (SET_ROLE(7)) — the other identity-crisis command, go read it too 🫶

---

and that's the whole page, bestie! this lil teachable moment came to you courtesy of the PostgreSQL 16.15 docs, dated 2026 — mwah, go forth and SET SESSION AUTHORIZATION responsibly 🌸💅🔥