Applied.
---
Bruce Momjian wrote:
Andrew Dunstan wrote:
Bruce Momjian wrote:
+ /* If it was 'invalid authorization', add .pgpass mention */
+ if (conn-dot_pgpass_used conn-password_needed
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-result,
Bruce Momjian wrote:
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
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 */
+
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 = 9.0 servers */
+
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian br...@momjian.us 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?
Robert Haas wrote:
On Thu, Mar 11, 2010 at 4:19 PM, Bruce Momjian br...@momjian.us 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
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),
+
Tom Lane wrote:
Bruce Momjian br...@momjian.us 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
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
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
Bruce Momjian wrote:
Tom Lane wrote:
Alvaro Herrera alvhe...@commandprompt.com 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
On Wed, Mar 10, 2010 at 11:52 AM, Bruce Momjian br...@momjian.us 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
Bruce Momjian br...@momjian.us 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
19 matches
Mail list logo
