From: Mark Cave-Ayland on 7 Dec 2007 13:29 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 8 Dec 2007 08:23 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
|
Pages: 1 Prev: xlogdump Next: LD_LIBRARY_PATH not honored on Debian unstable |