From: | Bruce Momjian <bruce(at)momjian(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Eamonn Martin <mas01em(at)gold(dot)ac(dot)uk>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Warning about invalid .pgpass passwords |
Date: | 2010-03-11 01:09:04 |
Message-ID: | 201003110109.o2B194R15682@momjian.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 <bruce(at)momjian(dot)us> http://momjian.us
EnterpriseDB http://enterprisedb.com
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2010-03-11 01:12:44 | Re: PD_ALL_VISIBLE flag error on 9.0 alpha 4 |
Previous Message | Tom Lane | 2010-03-11 01:07:08 | Re: Warning about invalid .pgpass passwords |