From: | Peter Geoghegan <peter(at)2ndquadrant(dot)com> |
---|---|
To: | Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>, Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Subject: | Re: enhanced error fields |
Date: | 2012-12-21 18:52:56 |
Message-ID: | CAEYLb_VEVCcc6OHdAxF5UNHFYSScOHyeo1A9GSnTEFd16S2Gyg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 11 December 2012 13:01, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Phil Sorber | 2012-12-21 19:07:20 | Re: [WIP] pg_ping utility |
Previous Message | Simon Riggs | 2012-12-21 18:47:56 | Re: Commits 8de72b and 5457a1 (COPY FREEZE) |