Обсуждение: libpq and error codes

I can't seem to find a reliable way to determine if the error from a 
call to PQconnectdb is due to an invalid username/password.  I can call 
PQstatus and it tells me CONNECTION_BAD, which I'd expect, and then 
PQerrorMessage gives me a plain text message that explains the reason, but
error messages can be localized.  A different version of PostgreSQL may 
decide to change the wording, so just doing a string comparison on the 
error message won't cut it.

What I need is a nice, numeric error code that I can compare to a known 
value that means invalid password. But there doesn't seem to be any 
function to do that. Am I just being blind? 

The reason I need this is that in our software, if the user tries to 
open a connection to a database and gets an authorization error of some 
kind, we pop up a username/password dialog and let them try again.  But 
if it's due to any other kind of problem (server down, etc), we give 
them the error message directly.

Dave Williss

Dave Williss <dwilliss@microimages.com> writes:
> I can't seem to find a reliable way to determine if the error from a 
> call to PQconnectdb is due to an invalid username/password.  I can call 
> PQstatus and it tells me CONNECTION_BAD, which I'd expect, and then 
> PQerrorMessage gives me a plain text message that explains the reason, but
> error messages can be localized.  A different version of PostgreSQL may 
> decide to change the wording, so just doing a string comparison on the 
> error message won't cut it.

Actually, in current releases you can --- the bad-password message is
deliberately not localized so that this is possible.  Compare to the
PQnoPasswordSupplied #define provided by libpq-fe.h.  (You can find
examples of this if you look into the source code for, for example,
psql.)

Of course, that pretty much sucks.  As of 8.3 there will be a status
function PQconnectionUsedPassword() to provide a cleaner API for
deciding whether you should issue a password prompt.

The more general idea that we should associate SQLStates with each
distinct error report inside libpq is still far off, I'm afraid.
It's a big job and no one has shown interest in tackling it.
        regards, tom lane