Mark Cave-Ayland <mark.cave-ayland@ilande.co.uk> writes:
> On Fri, 2007-12-07 at 11:03 -0500, Tom Lane wrote:
>> Hmmm ... it seems the problem is that we've defined
>> PQconnectionUsedPassword in such a way that it returns true (causing a
>> prompt) regardless of whether the reason for the connection failure was
>> a bad password or not. We might need to reconsider that API.
> Right. I think it depends on the interpretation of the
> PQconnectionUsedPassword function. If it should simply return whether or
> not the connection used a password or not (as it does now), then you
> could argue that it should be psql which should incorporate an
> additional check to determine whether the attempt was cancelled due to
> an invalid database name.
I think the problem is that we've tried to make PQconnectionUsedPassword
serve two masters. What it was originally designed for was to provide
a way for dblink to determine whether the user had provided an
authentication token, or was trying to impersonate the postgres user
on a remote connection. For that purpose its behavior is fine.
However, we (I think this is my fault :-() also tried to use it to
replace the ugly technique of checking for a specific error message
string to decide whether to prompt for a password. This example shows
that that doesn't work.
I can see three ways to proceed:
1. Revert the changes that removed dependencies on PQnoPasswordSupplied.
This is ugly but might be the safest solution for 8.3 --- we can always
revisit the issue later.
2. Try to adjust PQconnectionUsedPassword so that what it reports after
successful connection (which is what dblink cares about) isn't
necessarily defined the same as what it says after a failed connection.
This seems pretty ugly and nonintuitive.
3. Invent another libpq function, maybe PQconnectionNeedsPassword,
that does the right thing for the password-checking tests.
I don't think that leaving it as-is is acceptable --- if we do that,
we'll be encouraging client apps to adopt a broken API.
Thoughts?
regards, tom lane