SET_SESSION_AUTHORIZATION(7pg13)

Hiii bestie 💖 welcome to the SET_SESSION_AUTHORIZATION(7pg13) page from the PostgreSQL 13.23 documentation — manual name folded in right at the top, no copy-pasted header line, periodt. This one is all about switching who the session thinks you are, and it's lowkey iconic. Let's go 🎀

✨ NAME ✨

SET_SESSION_AUTHORIZATION — the command that sets 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 🌸

Okay so this command sets the session user identifier and the current user identifier of the current SQL session to be user_name. The user name can be written as either an identifier or a string literal. Using this command, it is possible, for example, to temporarily become an unprivileged user and later switch back to being a superuser. Iconic flexibility, honestly.

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; it can also be changed by SET ROLE (SET_ROLE(7)). The current user identifier is relevant for permission checking. So like, that one actually matters for the vibe check of permissions 🔥

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 identity swaps without the superuser card, bestie 💀

The SESSION and LOCAL modifiers act the same as for the regular SET(7) command.

The DEFAULT and RESET forms reset the session and current user identifiers to be the originally authenticated user name. These forms can be executed by any user. So everyone can reset back to their og self, cute 🎀

🧚 NOTES 🧚

SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function. That's the rule, no cap.

⭐ 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

🌈 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. 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. The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. Very PostgreSQL of it, slay ✨

The privileges necessary to execute this command are left implementation-defined by the standard. So the standard is like “figure it out” 💀

💜 SEE ALSO 💜

• SET ROLE (SET_ROLE(7)) — the other identity-switching baddie you should check out 🫶

---

mwah 💋 that's the whole page, bestie. Source/version: PostgreSQL 13.23 documentation · date: 2025 — now go flex that session authorization knowledge, periodt 🌟