On 2025-Nov-24, Tom Lane wrote: > Laurenz Albe <[email protected]> writes: > > On Mon, 2025-11-24 at 16:15 +0800, Calvin Guo wrote: > > 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.
For what it's worth, I think we break the SQL standard's security model by providing RESET ROLE and RESET SESSION AUTHORIZATION, neither of which the standard has. This means that in the standard model you have commands to lower your privilege, but once you've lowered them, you cannot return (in the same connection) to what you had. Section 4.42 "Basic security model" of the 2023 edition of the standard explains this. There is a stack of authorizations -- but when you do SET SESSION AUTHORIZATION, you don't add another cell of the stack. Instead, the current session user is replaced. They provide no way to return. The stack is used for <routine invocation>, <externally-invoked procedure>, triggered action, <execute statement>, or <direct SQL statement> and the stack cell so created is automatically removed when that operation completes. Of course, I may be misreading the standard. -- Álvaro Herrera Breisgau, Deutschland — https://www.EnterpriseDB.com/ "No renuncies a nada. No te aferres a nada."
