Re: patch for 9.2: enhanced errors

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: Florian Pflug <fgp(at)phlo(dot)org>
Cc: Alvaro Herrera <alvherre(at)commandprompt(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: patch for 9.2: enhanced errors
Date: 2011-07-28 04:11:25
Message-ID: CAFj8pRAPLba90n_R9UCnCFUnz3JyVdL4Kqarty=RA6Yf=ZTu+Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

2011/7/28 Florian Pflug <fgp(at)phlo(dot)org>:
> On Jul27, 2011, at 23:20 , Pavel Stehule wrote:
>> this is a refreshed patch. Only constraints and RI is supported now.
>> There is about 1000 ereport calls, where a enhanced diagnostics should
>> be used, but probably we don't modify all in one time.
>
> I wonder if it wouldn't be better to have something like the machinery
> around ErrorContextCallback to fill in the constraint details. You'd then
> only need to modify the places which initiate constraint checks, instead
> of every single ereport() in the constraint implementations.
>
> Just a wild idea, though - I haven't check whether this is actually
> feasible or no.

I though about this too, but sometimes is relative difficult to
specify a fields before exception -- see a ri_triggers part.
TABLE_NAME and TABLE_SCHEMA should not contains a name of processed
table, but name of error, that is related to error. It can be
different. But if we would to use a enhanced errors for "in"
functions, then some injection into ErrorContextCallback should be
necessary - but again - the these fields are no related to function's
scope - so it mean a more manipulation with ErrorContext.

Regards

Pavel Stehule

>
> best regards,
> Florian Pflug
>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers
>

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Simon Riggs 2011-07-28 07:46:38 Re: cheaper snapshots
Previous Message Tom Lane 2011-07-28 03:28:00 Re: Ripping out pg_restore's attempts to parse SQL before sending it