SET_SESSION_AUTHORIZATION(7pg14)

💅 SET_SESSION_AUTHORIZATION (7pg14)

okay so bestie, welcome to the glow-up page for SET_SESSION_AUTHORIZATION — straight out of the PostgreSQL 14.24 Documentation, no cap. This is the command that lets your current session switch up who it says it is. main character energy, but like, with permissions. ✨

---

🎀 NAME 🎀

SET_SESSION_AUTHORIZATION — the icon that sets the session user identifier and the current user identifier of the current session. two IDs, one command, slay. 👑

---

🌸 SYNOPSIS 🌸

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

look at her. three whole forms. she's flexible. 🦋

---

💖 DESCRIPTION 💖

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. yes, both. she's not picky. 💫

Using this command, it is possible — for example — to temporarily become an unprivileged user and later switch back to being a superuser. literally the costume change of the SQL world, iykyk. 🧚

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. The current user identifier is relevant for permission checking. so like… the current user is the one doing the actual permission-checking, periodt. 🔥

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. that's the vibe check you cannot skip, bestie — no superuser, no identity theft. 💀

The SESSION and LOCAL modifiers act the same as for the regular SET command. same energy, different 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 if you ever get lost, you can always come home. 🌈

---

⭐ NOTES ⭐

🚨 SET SESSION AUTHORIZATION cannot be used within a SECURITY DEFINER function. like, it's giving "not allowed in there." respect the boundary. 🙈

---

🍓 EXAMPLES 🍓

okay this is the part where she serves. watch. 👀

    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

peter walked so paul could run. ate and left absolutely no crumbs. 💅

---

💜 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. (read: nobody's using them, ngl.) 😭

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. fr fr — why gatekeep something for no reason. 🤷‍♀️

The SESSION and LOCAL modifiers are a PostgreSQL extension, as is the RESET syntax. homegrown excellence. 🌱

The privileges necessary to execute this command are left implementation-defined by the standard. so the standard was like "you figure it out" and dipped. 💀

---

🦋 SEE ALSO 🦋

• SET ROLE (SET_ROLE(7)) — her sister, also iconic, also worth a read 🫶

---

and that's the page, bestie!! 💖 no cap, you're now fully fluent in session identity shenanigans. this whole thing shipped with PostgreSQL 14.24, dated 2026 — so like, bookmark it, screenshot it, put it on your fridge. 🎀✨👑