Tom Lane wrote:
> Bruce Momjian <bruce(at)momjian(dot)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 label ("error_return") in
PQconnectPoll(), and placed the code in a new function.
> > 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
OK, parentheses removed.
> 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.
Modifying the backend to issue this hint seems like overkill, unless we
have some other use for it.
> 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
I originally considered using the SQLSTATE but found few uses of it in
the frontend code. However, I agree it is the proper solution so I now
coded it that way, including a loop to convert from the 6-bit sqlstate
to base-10. (FYI, the same C file hardcodes ERRCODE_APPNAME_UNKNOWN as
a string for historical reasons, but I didn't do that.)
Updated patch attached.
Bruce Momjian <bruce(at)momjian(dot)us> http://momjian.us
PG East: http://www.enterprisedb.com/community/nav-pg-east-2010.do
In response to
pgsql-hackers by date
|Next:||From: Tom Lane||Date: 2010-03-11 01:07:08|
|Subject: Re: Warning about invalid .pgpass passwords |
|Previous:||From: Fujii Masao||Date: 2010-03-11 00:51:29|
|Subject: Re: Re: Hot Standby query cancellation and Streaming Replication integration|