Skip site navigation (1) Skip section navigation (2)

Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

From: Chris Travers <chris(at)metatrontech(dot)com>
To: Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Date: 2009-12-16 20:48:20
Message-ID: 5ed37b140912161248r7d9e8afcgb2250ad8b148515b@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-bugs
On Wed, Dec 16, 2009 at 12:35 PM, Kevin Grittner
<Kevin(dot)Grittner(at)wicourts(dot)gov> wrote:
> "Chris Travers" <chris(dot)travers(at)gmail(dot)com> wrote:
>
>> I am noticing that that a failed database connection results in an
>> unusable SQLSTATE in libpq, and a very different SQLSTATE than the
>> backend registers.
>
> Well, if the client fails to connect to the server, I'm not sure how
> the server could communicate its SQLSTATE to the client, in order to
> force them to match.

It does send an error message.  Currently I end up parsing that error
message and checking to see if a connection is active.  Unfortunately
this becomes annoying where the locale of the PostgreSQL instance
could change the messages received.

It would be nice to have at least an option for software to pick up a
code as to why a connection request fails instead of having to try to
deal with feedback intended for a human, but I would settle for at
least a SQLSTATE that indicated a connection problem instead of a
transaction issue (08001 or 08004) since these would be a lot less
ambiguous on the program interface side.

Best Wishes,
Chris Travers

In response to

pgsql-bugs by date

Next:From: Magnus HaganderDate: 2009-12-16 21:03:48
Subject: Re: pgstat wait timeout (by Robert Schnabel)
Previous:From: Kevin GrittnerDate: 2009-12-16 20:35:07
Subject: Re: BUG #5246: Misleading/inconsistent SQLSTATE behavior

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group