Applied.
---
Bruce Momjian wrote:
> Andrew Dunstan wrote:
> >
> >
> > Bruce Momjian wrote:
> > > + /* If it was 'invalid authorization', add .pgpass mention */
> > > + if (conn->dot_pgpass_used && conn->pas
Andrew Dunstan wrote:
>
>
> Bruce Momjian wrote:
> > + /* If it was 'invalid authorization', add .pgpass mention */
> > + if (conn->dot_pgpass_used && conn->password_needed && conn->result &&
> > + /* only works with >= 9.0 servers */
> > + strcmp(PQresultErrorField(conn->
Bruce Momjian wrote:
+ /* If it was 'invalid authorization', add .pgpass mention */
+ if (conn->dot_pgpass_used && conn->password_needed && conn->result &&
+ /* only works with >= 9.0 servers */
+ strcmp(PQresultErrorField(conn->result, PG_DIAG_SQLSTATE),
Robert Haas wrote:
> On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian wrote:
> > ? ? ? ?$ sql -h localhost test
> > ? ? ? ?psql: FATAL: ?password authentication failed for user "postgres"
> > ? ? ? ?password retrieved from .pgpass
>
> I find this not quite explicit enough for my taste. Maybe somet
On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian wrote:
> $ sql -h localhost test
> psql: FATAL: password authentication failed for user "postgres"
> password retrieved from .pgpass
I find this not quite explicit enough for my taste. Maybe something like this?
the failing pa
Tom Lane wrote:
> Bruce Momjian writes:
> > + #define ERRCODE_INVALID_PASSWORD_SPECIFICATION MAKE_SQLSTATE('2','8',
> > '0','0','1')
>
> Oh, another thought: you're infringing on SQL-committee-controlled code
> space there. Probably 28P01 would be a safer choice.
OK, updated patch with code "2
Bruce Momjian writes:
> + #define ERRCODE_INVALID_PASSWORD_SPECIFICATION MAKE_SQLSTATE('2','8',
> '0','0','1')
Oh, another thought: you're infringing on SQL-committee-controlled code
space there. Probably 28P01 would be a safer choice.
regards, tom lane
--
Sent via pg
Bruce Momjian writes:
ERRCODE_INVALID_PASSWORD_SPECIFICATION
BTW, why not just "ERRCODE_INVALID_PASSWORD"? The extra word doesn't
seem to promote anything except carpal tunnel syndrome.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgr
Tom Lane wrote:
> Bruce Momjian writes:
> > Alvaro Herrera wrote:
> >> This bit seems strange ... I think we just do strcmp() to compare
> >> sqlstates?
>
> > Uh, the PQresultErrorField is a string, while
> > ERRCODE_INVALID_PASSWORD_SPECIFICATION is a 4-byte value in base-64.
> > Yea, it's t
Bruce Momjian writes:
> Alvaro Herrera wrote:
>> This bit seems strange ... I think we just do strcmp() to compare sqlstates?
> Uh, the PQresultErrorField is a string, while
> ERRCODE_INVALID_PASSWORD_SPECIFICATI is a 4-byte value in base-64.
> Yea, it's true. For excitement, see the MAKE_SQL
Alvaro Herrera wrote:
> Bruce Momjian wrote:
>
> > + static void
> > + dot_pg_pass_warning(PGconn *conn)
> > + {
> > + /* If it was 'invalid authorization', add .pgpass mention */
> > + if (conn->dot_pgpass_used && conn->password_needed && conn->result &&
> > + /* only works with >=
Bruce Momjian wrote:
> + static void
> + dot_pg_pass_warning(PGconn *conn)
> + {
> + /* If it was 'invalid authorization', add .pgpass mention */
> + if (conn->dot_pgpass_used && conn->password_needed && conn->result &&
> + /* only works with >= 9.0 servers */
> + a
Bruce Momjian wrote:
> Tom Lane wrote:
> > Bruce Momjian 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
Tom Lane wrote:
> Bruce Momjian 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 b
Bruce Momjian 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 seem
Tom Lane wrote:
> Bruce Momjian writes:
> > The attached patch reports the fact that .pgpass was used if the libpq
> > connection fails:
>
> The test is in a very inappropriate place --- it will be missed by
> several fully-supported code paths.
Agreed. I moved it to the error return label ("er
Bruce Momjian writes:
> The attached patch reports the fact that .pgpass was used if the libpq
> connection fails:
The test is in a very inappropriate place --- it will be missed by
several fully-supported code paths.
> I am not sure if I like the parentheses or not.
I don't like 'em. If you d
On Wed, Mar 10, 2010 at 11:52 AM, Bruce Momjian wrote:
> The attached patch reports the fact that .pgpass was used if the libpq
> connection fails:
+ /*
+* If the connection failed, we should mention that
+* we got the password from .pgpass in case that
+*
Bruce Momjian wrote:
> Tom Lane wrote:
> > Alvaro Herrera writes:
> > > It had to do with me having a bogus password in .pgpass (so psql was
> > > first trying empty password, then the one in .pgpass, and both failing).
> > > Pilot error. However, I'd say that we ought to give a notice if the
> >
19 matches
Mail list logo
