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 'em. If you don't have enough confidence in the message to
be replacing the normal error string, you probably shouldn't be doing
this at all. We'll look silly if we attach such a comment to a message
that indicates a network failure, for example; and cases where the
comment is actively misleading would be even worse.
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.
The main argument against this is probably that it would tell a bad
guy that he's got a valid username but not a valid password. Not
sure if that's a serious issue or not --- I seem to recall that we
are exposing validity of user names already (or was that database
names?). It would also mean that the new message only triggers when
talking to a 9.0+ server, but since we've gotten along without it
till now, that aspect doesn't bother me at all.
A compromise would be to check for
ERRCODE_INVALID_AUTHORIZATION_SPECIFICATION, which in combination
with the knowledge that we got asked for a password would give
fairly high confidence though not certainty that the problem is a bad
password.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
