On 1 May 2012 13:21, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> COLUMN_NAME - contains missing or inaccessible column name or empty string
> CONSTRAINT_NAME - a name of constraint caused error
> CONSTRAINT_SCHEMA - a name of schema where constraint is defined -
> usually same as table schema in PostgreSQL
> SCHEMA_NAME - schema name of table that caused exception
> ROUTINE_NAME, ROUTINE_SCHEMA name and schema of function that caused
> exception - this doesn't mean function where exception was raised
> TABLE_NAME - a name of table that caused exception
> TRIGGER_NAME, TRIGGER_SCHEMA - name and schema of trigger that caused exception
I'm strongly in favour of this. Certainly, the need to translate an
error into a domain-specific error message within the application is a
common one, and there's currently no well-principled way to do so,
certainly not across locales. What I'd also like to see, which is
something that I've agitated about in the past without much luck, is
for a new severity level, along the lines of a "severe error". The
idea of this is to make a representation that the error in question is
one that the DBA should reasonably hope to never see. That is quite
distinct from the nature of what usually form the large majority of
errors - routine integrity constraint violations and things like that.
Do you suppose you could incorporate this into your design?
It would be nice if in addition to this, a domain-specific error
message could be specified within the database, associated with each
constraint, but I suppose that the details of the API would require a
great deal of bike shedding.
--
Peter Geoghegan http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services