Re: proposal: additional error fields

2012/5/1 Peter Geoghegan <peter(at)2ndquadrant(dot)com>:
> On 1 May 2012 13:21, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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