Tom Lane wrote: > Bruce Momjian <br...@momjian.us> writes: > > Tom Lane wrote: > >> I'm inclined to think that maybe we should make the server return a > >> distinct SQLSTATE for "bad password", and have libpq check for that > >> rather than just assuming that the failure must be bad password. > > > Modifying the backend to issue this hint seems like overkill, unless we > > have some other use for it. > > I wouldn't suggest it if I thought it were only helpful for this > particular message. It seems to me that we've spent a lot of time > kluging around the lack of certainty about whether a connection failure > is a password issue. Admittedly a lot of that was between libpq and its > client, but the state of affairs on the wire isn't great either.
Yes, I have seen that myself in psql. > I'm not convinced we have to do it that way, but now is definitely > the time to think about it before we implement yet another > sort-of-good-enough kluge. Which is what this is. True. Should we just hold this all for 9.1 or should I code it and let's look at the size of the patch? -- Bruce Momjian <br...@momjian.us> http://momjian.us EnterpriseDB http://enterprisedb.com PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
