BUG #5246: Misleading/inconsistent SQLSTATE behavior

From: "Chris Travers" <chris(dot)travers(at)gmail(dot)com>
To: pgsql-bugs(at)postgresql(dot)org
Subject: BUG #5246: Misleading/inconsistent SQLSTATE behavior
Date: 2009-12-16 00:16:26
Message-ID: 200912160016.nBG0GQG3029133@wwwmaster.postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs


The following bug has been logged online:

Bug reference: 5246
Logged by: Chris Travers
Email address: chris(dot)travers(at)gmail(dot)com
PostgreSQL version: 8.1.18
Operating system: Fedora Linux 12
Description: Misleading/inconsistent SQLSTATE behavior
Details:

Hi all;

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.

For example, if a connection fails due to a database not found, the backend
registers 3D000 as a SQL state, but the front-end registers 25P01. If a
login fails, the back-end registers 28000 but the front-end registers 25P01
again.

25P01 is "no_active_sql_transaction" and provides little information to the
programmer as to how to handle the error. I may be missing something but
the error looks to be entirely meaningless as it relates to a failed
connection attempt as I, as a programmer, am loathe to trust that a generic
transaction-related status message would be only used to track connection
problems.

From a programming perspective, it would be ideal for the same SQLSTATE
triggered on the back-end to be available to the front-end. This leads to
a number of very substandard workarounds. This might not be addressable
within stable versions, but it would be very nice to see it fixed.

Best Wishes,
Chris Travers

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Mark Williamson 2009-12-16 02:31:00 Optimal platform for pg?
Previous Message Tom Lane 2009-12-15 20:52:53 Re: statement_timeout is not cancelling query