-Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Tom Lane
> Sent: Tuesday, January 27, 2004 1:35 PM
>
> "Ezra Epstein" <[EMAIL PROTECTED]> writes:
> >> I do not think SET SESSION AUTH is a suitable replacement for logging
> >> in. For one thing, it doesn'
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 27, 2004 10:46 AM
> To: [EMAIL PROTECTED]
> Cc: Bruce Momjian; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> "Ezra Eps
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
Ezra Epstein wrote:
I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
password.
Uh, a password? What purpose would that serve?
Indeed. SET SESSION AUTH is already allowed only to superusers --- a
superuser
> -Original Message-
> From: Tom Lane [mailto:[EMAIL PROTECTED]
> Sent: Monday, January 26, 2004 7:56 PM
> To: Bruce Momjian
> Cc: [EMAIL PROTECTED]; PostgreSQL-development
> Subject: Re: [HACKERS] Extending SET SESSION AUTHORIZATION
>
>
> Bruce Momjian <[EMAI
"Ezra Epstein" <[EMAIL PROTECTED]> writes:
>> 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
> OK, what are GUC settings. Can SET SESSION AUTH be extended to do this as
> needed?
Not very easily; it's not
"Ezra Epstein" <[EMAIL PROTECTED]> 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 IF
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ezra Epstein wrote:
>> I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
>> password.
> Uh, a password? What purpose would that serve?
Indeed. SET SESSION AUTH is already allowed only to superusers --- a
superuser hardly nee
Ezra Epstein wrote:
>
> I'd like to extend SET SESSION AUTHORIZATION to support a form which takes a
> password. Looking at the source it seems, other than changes to the parser,
> there are only 2 relevant functions in 2 files that would be affected. Each
> function is quite small and its funct
