Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> I'd say that you definitely don't want a user password prompt if libpq's
> password is wrong, since I can see this would break a lot of scripts
> that weren't launched directly from the shell
Agreed, we don't want the behavior to suddenly turn interactive when
the user expected it not to be.
> As for the second point, I'm not too worried about how many times you
> are asked for the password - I personally am happy with the one attempt
> as it stands at the moment.
On reflection, this ought to be an application decision anyway; libpq
isn't going to be a good place to do it since it can have no memory
of how many times the "same" connection was tried.
Also, on further reflection I realize that PQconnectionUsedPassword
is broken for dblink's usage too! It's currently defined, in essence,
as "the connection used a password-based auth method". But that fails
to distinguish where it got the password from. In particular, as of
CVS HEAD it's still possible for a non-superuser to impersonate
postgres on a dblink connection, if the DBA has taken the
not-unreasonable step of setting up a ~/.pgpass in postgres' home
directory.
Fortunately, existing release branches don't use that technique,
or we'd have a live security problem here. But anyway, this seemingly
trivial patch has turned out to be pretty snake-bit :-(
So what I think we must do is split the function into two:
PQconnectionNeedsPassword: true if server demanded a password and there
was none to send (hence, can only be true for a failed connection)
PQconnectionUsedPassword: true if server demanded a password and it
was supplied from the connection function's argument list, *not*
from environment or a password file.
Offhand it looks like only dblink needs the second version ---
all of our client-side code wants the first one.
Barring objections I'll go code this up ...
regards, tom lane
