Álvaro Herrera <alvherre@kurilemu.de> writes: > On 2025-Nov-24, Tom Lane wrote: >> I don't think so. They are just shorthand for issuing a SET to the >> original value, so how do they break the model in a way that that >> doesn't?
> No, because the new user doesn't have privs to become the previous one.
Don't think you can make that argument from the standard, since it explicitly disclaims saying what privs are required.
> It would be more > secure to have a mechanism where the connection is initially > unauthenticated altogether (which means: it's not a valid SQL session), > becomes authenticated at the pooler's will, and returns to > unauthenticated state as the pooler decides. Critically, from > unauthenticated state you shouldn't be able to become superuser.
I don't like the idea that a pooler or pretend-to-be pooler can eat up a backend session without having authenticated at all. Also, exactly what does "becomes authenticated at the pooler's will" mean? There had better be some actual authentication happening somewhere.
A restriction that it can only happen when TLS authentication is used, and the pooler is using its service account?
