Re: enhanced error fields

On 11 December 2012 13:01, Pavel Stehule <pavel.stehule@gmail.com> wrote:
> There are two basic aspects of design
>
> * usability - we would to remove necessity of parsing error messages
> for getting interesting data, it decrease dependency on current error
> messages - then I am thinking so some informations about triggers or
> functions where exception was born are practical (current
> implementation is different task - we can find better solution than I
> proposed highly probably)
>
> * compatibility - personally, lot of diagnostics fields are very vague
> defined, so here can be lot of issues - I have no experience with DB2
> or Oracle, so I cannot to speak more, but we should to say, what we
> expect.

Me neither.

> I afraid so constraint name is not afraid

I'm sorry, I don't follow you here.

> postgres=# create table a (a int primary key);
> CREATE TABLE
> postgres=# create table b (b int references a(a));
> CREATE TABLE
> postgres=# insert into b values (10);
> ERROR:  insert or update on table "b" violates foreign key constraint "b_b_fkey"
> DETAIL:  Key (b)=(10) is not present in table "a".
> postgres=# \set VERBOSITY verbose
> postgres=# insert into b values (10);
> ERROR:  23503: insert or update on table "b" violates foreign key
> constraint "b_b_fkey"
> DETAIL:  Key (b)=(10) is not present in table "a".
> LOCATION:  ri_ReportViolation, ri_triggers.c:3222
> postgres=# insert into a values(10);
> INSERT 0 1
> postgres=# insert into b values (10);
> INSERT 0 1
> postgres=# delete from a;
> ERROR:  23503: update or delete on table "a" violates foreign key
> constraint "b_b_fkey" on table "b"
> DETAIL:  Key (a)=(10) is still referenced from table "b".
> LOCATION:  ri_ReportViolation, ri_triggers.c:3232
>
> there are two different bugs - with same ERRCODE and constraint name -
> once is problem on "b", second on "a"
>
> so constraint_table is interesting information

Really? I'm not so sure that that's a distinct that the user would
have to care about, or at least care much about. I defer to others
here. Certainly, I am generally conscious of the fact that we don't
want to create an excessive number of fields.

> My implementation is probably too dumb - but a question - "where
> exception is coming from?" is relative typical - but we can to clean
> implementation. I see a issue in definition. Usually I am interesting
> about most deep custom code - not most deep code.

I think that knowing where an exception comes from is not useful
information for end-users. Therefore, I am unconvinced of the need to
present information to end users that is based on that. That's my
difficulty.

> so I am not against to removing some fields, but constraint_table and
> routine_name is useful and we should to produce this information.

I'm afraid that you and I differ on that.

>> To make logging less verbose, TABLE NAME isn't consistently split out
>> as a separate field - this seems fine to me, since application code
>> doesn't target logs:

> uff, no - I don't like it - it is not consistent and I don't think so
> one row more is a issue. But is a question if we don't need a second
> "VERBOSE" level for showing these fields - maybe VERBOSE_ENHANCED or
> some similar

VERBOSE_ENHANCED? I'm not sure about that. If you think it's important
for them to be consistent, I concede the point.

> we don't need log these fields usually ??

Well, I don't think we *usually* need to log *any* verbose fields.

-- 
Peter Geoghegan       http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training and Services