Tom Lane wrote:
> Christopher Browne <[EMAIL PROTECTED]> writes:
>> Centuries ago, Nostradamus foresaw when [EMAIL PROTECTED] ("Jim C.
>> Nasby") would write:
>>> In PostgreSQL, there's currently no way to assume the identity of
>>> another user.
>
>> I'm confused at that...
>
>> There seem to be ways at time of connection establishment, whether
>> via the psql "-U" option, or the PGconnect "dbuser=foo" option, or
>> during a psql session via "\c - newuser".
>
> Not to mention SET SESSION AUTHORIZATION.
Chris, all the options you mention require the entry of a password, or
for SET SESSION AUTHORIZATION, that the original connection was made by
a superuser (which in turn would have required entry of a password.)
It's possible to circumvent this with trust authentication, but the
PostgreSQL documentation recommends against general use of trust
authentication (and I agree with that recommendation in a production
environment.)
As described in other messages in this thread, putting a scheduler in
the database would allow authentication to be done at the time the job
is set up, and then the job to be run without reauthorization.
--
Guy Rouillier
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
