Re: proposal: additional error fields - Mailing list pgsql-hackers

From Pavel Stehule
Subject Re: proposal: additional error fields
Date
Msg-id CAFj8pRBhYT2ztQT207-i4zRPzGAugVG-JWt5i5sfQjethv54KA@mail.gmail.com
Whole thread Raw
In response to Re: proposal: additional error fields  (Peter Geoghegan <peter@2ndquadrant.com>)
Responses Re: proposal: additional error fields
List pgsql-hackers
2012/5/1 Peter Geoghegan <peter@2ndquadrant.com>:
> 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.

yes, this is reason why I wrote this patch. Additional benefit is
significantly richer exception data model, that can be used for PL

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?

I don't understand well, can you explain it.

I don't plan to solve more issues in one patch, but it can be
inspiration for next work.

Regards

Pavel

>
> 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


pgsql-hackers by date:

Previous
From: Peter Geoghegan
Date:
Subject: Re: proposal: additional error fields
Next
From: Robert Haas
Date:
Subject: Re: Future In-Core Replication