The following bug has been logged online: Bug reference: 5246 Logged by: Chris Travers Email address: chris.trav...@gmail.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
