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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-bugs by date

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