From: Mark Cave-Ayland on
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.

On first glance, libpq appears to return just CONNECTION_BAD and an
error message, so I'm not sure whether we can easily detect the
difference between an incorrect password and an invalid database name :(
Is there an additional status code in PGconn that can be used to
determine the exact cause of connection failure?


ATB,

Mark.

--
ILande - Open Source Consultancy
http://www.ilande.co.uk



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

From: Alvaro Herrera on
Tom Lane wrote:

> 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.

> 3. Invent another libpq function, maybe PQconnectionNeedsPassword,
> that does the right thing for the password-checking tests.

My vote goes to (3), if the work can be done quickly, or (1) if it
can't.

--
Alvaro Herrera http://www.PlanetPostgreSQL.org/
"When the proper man does nothing (wu-wei),
his thought is felt ten thousand miles." (Lao Tse)

---------------------------(end of broadcast)---------------------------
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate