On 11 December 2012 13:01, Pavel Stehule <pavel.steh...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
