"Ezra Epstein" <eepstein@prajnait.com> writes:
>>> I'd like to extend SET SESSION AUTHORIZATION to support a form
>>> which takes a password.
>>
> Uh, a password? What purpose would that serve?
> For exactly the opposite usage: allowing a non-privileged user to take on a
> different authorization IFF a password is also supplied. This allows a user
> to use an existing connection (so, for example, connection pooling works)
> and not require a high priv'd account to then act as a specific (and
> specifically priv'd) user of the system.
I do not think SET SESSION AUTH is a suitable replacement for logging
in. For one thing, it doesn't apply per-user GUC settings. For
another, using it this way in a pooling environment would be completely
insecure --- what if you forget to "log out", or your attempt to do so
is dropped because it was inside a failed transaction block?
Another objection to doing things this way is that it would just about
force people to embed passwords into their SQL scripts, creating another
serious source of insecurity.
regards, tom lane
