Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior - Mailing list pgsql-bugs

From Chris Travers
Subject Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Date
Msg-id 5ed37b140912161316v376ae755w3408b41e2e3e2865@mail.gmail.com
Whole thread Raw
In response to Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-bugs
trying again.  Sorry for the duplicate.

On Wed, Dec 16, 2009 at 1:12 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> "Chris Travers" <chris.travers@gmail.com> writes:
>> I am noticing that that a failed database connection results in an unusa=
ble
>> SQLSTATE in libpq, and a very different SQLSTATE than the backend
>> registers.
>
>> For example, if a connection fails due to a database not found, the back=
end
>> registers 3D000 as a SQL state, but the front-end registers 25P01. =A0If=
 a
>> login fails, the back-end registers 28000 but the front-end registers 25=
P01
>> again.
>
> Exactly what "frontend" are you talking about here? =A0Because what this
> sounds like to me is a client-side programming error. =A0It's certainly
> not the backend's fault, and I doubt it is libpq's either.



I am using DBD::Pg.

I asked about it on #postgresql and was told this was the SQLSTATE code
passed up from libpq (by the author of DBD::Pg).  Several other folks
there seemed to concur.

It is certainly not a backend error.  The back-end logs correct errors
when logging is set to verbose.

Best Wishes,
Chris Travers

pgsql-bugs by date:

Previous
From: Tom Lane
Date:
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Next
From: Tom Lane
Date:
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior