To: Christoph Zwerschke <cito@online.de>
Cc: pgsql-interfaces@postgresql.org
Subject: Re: Interpreting PostgreSQL error messages 
In-reply-to: <435E97CD.9000602@online.de> 
References: <435E97CD.9000602@online.de>
Comments: In-reply-to Christoph Zwerschke <cito@online.de>
	message dated "Tue, 25 Oct 2005 22:38:37 +0200"
Date: Tue, 25 Oct 2005 23:34:21 -0400
Message-ID: <1287.1130297661@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Christoph Zwerschke <cito@online.de> writes:
> I know there is a "SQLSTATE" code and the doco says:
> "Applications that need to know which error condition has occurred
> should usually test the error code, rather than looking at the textual
> error message. The error codes are less likely to change across
> PostgreSQL releases, and also are not subject to change due to
> localization of error messages. "

> But first, SQLSTATE is not accesible from many programming interfaces,

So you need to use a less broken interface...

> and second, anyway it would not help because it would not contain a hint
> about for instance, which foreign key constraint has been violated.

The SQL spec thinks that error reports should contain additional
optional fields, such as "name of affected table" and "name of affected
column" for a column constraint violation error.  (I'm handwaving here
but that's the general idea.  The SQLSTATE code would tell you which
additional fields are available.)  Providing such fields would eliminate
the need for client-side code to parse human-readable messages.  We have
not got round to implementing any of this yet, but the protocol and
backend error-handling infrastructure are prepared to deal with extra
fields of this ilk.

Obviously, whenever that does happen, you'll need an even less broken
client library to get at the extra fields.  So if you open the bidding
by saying "I won't use a tool that has heard of SQLSTATE", the answer
is going to be "tough luck".

			regards, tom lane