Interpreting PostgreSQL error messages

From: Christoph Zwerschke <cito(at)online(dot)de>
To: pgsql-interfaces(at)postgresql(dot)org
Subject: Interpreting PostgreSQL error messages
Date: 2005-10-25 20:38:37
Message-ID: 435E97CD.9000602@online.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

This is a general question about dealing with PostgreSQL error messages
in programs using client interfaces to PostgreSQL. What is the best way
to process the error messages and present them to users of for instance,
a web application, in a user friendly way?

Let's take a concrete example: An e-shop application, and the database
has a table "customers" and tables "orders" and "invoices" with foreign
key constraints on customers. The e-shop has a CGI program for
maintaining customers that also allows deleting customers if they have
no pending orders or invoices.

The code could look like this:

----------------------------------------------

try:

delete from customers where customer_id=$id

exception:

if postgres_error_message.ends_with \
"key in customers still referenced from orders":

print "There are still orders from the customer!"

else if postgres_error_message.ends_with \
"key in customers still referenced from invoices":

print "There are still invoices for the customer!"

else:

print postgres_error_message

----------------------------------------------

You get the idea: If there is an error like the violation
of a foreign key constraint, the program will catch and
"translate" the error message for the usage, printing a
more a user friendly message instead of bothering you with
database specific details and terms like "constraint",
"table", "key" etc. The most frequent and likely error
situations are caught like this. Only if the program cannot
interpret the error message, it will fall back to printing
out the original PostgreSQL error message.

I think this is quite elegant and easy for the programmer,
but there is a big drawback:

1) The error messages can vary with the PostgreSQL version.
2) The error messages also depend on the localization.

One could resolve 2) by forcing lc_messages = 'C' in
postgresql.conf, but then the user would be confronted
with English messages instead of the localized messages
in the "fallback" case.

Is there any other elegant solution?

I think it would be nice to have some normed "machine readable"
kind of error message besides the "humand readable" message
that PostgreSQL provides.

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,
and second, anyway it would not help because it would not contain a hint
about for instance, which foreign key constraint has been violated.

Any ideas or comments on this?

-- Christoph

Responses

Browse pgsql-interfaces by date

  From Date Subject
Next Message Tom Lane 2005-10-26 03:34:21 Re: Interpreting PostgreSQL error messages
Previous Message Louis Castoria 2005-10-25 17:04:33 libpq status question