Received: from localhost (maia-4.hub.org [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id B024B9F9C55 for ; Fri, 24 Aug 2007 13:41:57 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 25806-04 for ; Fri, 24 Aug 2007 13:41:53 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.5 Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id 570609F9C2D for ; Fri, 24 Aug 2007 13:41:53 -0300 (ADT) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.14.1/8.14.1) with ESMTP id l7OGfp3P002159; Fri, 24 Aug 2007 12:41:51 -0400 (EDT) To: Dave Williss cc: pgsql-interfaces@postgresql.org Subject: Re: libpq and error codes In-reply-to: <46CEED0D.1040506@microimages.com> References: <46CEED0D.1040506@microimages.com> Comments: In-reply-to Dave Williss message dated "Fri, 24 Aug 2007 09:37:01 -0500" Date: Fri, 24 Aug 2007 12:41:51 -0400 Message-ID: <2158.1187973711@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200708/12 X-Sequence-Number: 6606 Dave Williss 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