From: Tom Lane <tgl@sss.pgh.pa.us>
To: Laurenz Albe <laurenz.albe@cybertec.at>
cc: Calvin Guo <newoakllc2023@gmail.com>, pgsql-general@lists.postgresql.org
Subject: Re: set role command
In-reply-to: <464edf94a18cf09a49e275d9e9d723949d7682d3.camel@cybertec.at>
References: <CA+bysH_or91tt7r0gKLJtw5Wp+DEYwnaRJoTvLfKO33dcdQ_rQ@mail.gmail.com> <464edf94a18cf09a49e275d9e9d723949d7682d3.camel@cybertec.at>
Comments: In-reply-to Laurenz Albe <laurenz.albe@cybertec.at>
	message dated "Mon, 24 Nov 2025 13:57:49 +0100"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <955749.1764001100.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Mon, 24 Nov 2025 11:18:20 -0500
Message-ID: <955750.1764001100@sss.pgh.pa.us>
Archived-At: <https://www.postgresql.org/message-id/955750.1764001100%40sss.pgh.pa.us>
Precedence: bulk

Laurenz Albe <laurenz.albe@cybertec.at> writes:
> On Mon, 2025-11-24 at 16:15 +0800, Calvin Guo wrote:
>> I really feel, once you "set role usera", you should behave like usera,=
 you should
>> NOT have the power say: hi, I can assume my super user power whenever I=
 want.
>> As this make the "set role usera" pretty much useless.

> I respect your feelings, but that is not how SET ROLE works.
> The current behavior is intentional and documented in
> https://www.postgresql.org/docs/current/sql-set-role.html

And it's also required by the SQL standard, which is very clear
that "user identifier" and "role" are different things, and
SET ROLE only changes the latter.

> There is SET SESSION AUTHORIZATION, which acts somewhet more like you wa=
nt,
> except that you can become a superuser again with RESET SESSION AUTHORIZ=
ATION.

In the standard, the privileges required to do SET SESSION
AUTHORIZATION are "implementation defined", which means we could
change how it works without breaking standards conformance.
We'd still be breaking backwards compatibility, though --- for
instance, pg_dump dumps made with --use-set-session-authorization
would stop working.  I think that a proposal to change this has
very little chance of succeeding.

The best way to lock things down is to start a new session under
the restricted user name.

			regards, tom lane