Re: enhanced error fields

2012/12/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Geoghegan <peter(at)2ndquadrant(dot)com> writes:
>> On 29 December 2012 05:04, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> wrote:
>>>> So I'm with Peter G on this: the existing CONTEXT mechanism is good
>>>> enough, we do not need to split out selected sub-parts of that as
>>>> separate error fields. Moreover, doing so would provide only an utterly
>>>> arbitrary subset of the context stack: who's to say whether it would be
>>>> more important to report the most closely nested function, or the
>>>> outermost one?
>
>>> I don't agree with this argument - you can say too "COLUMN_NAME,
>>> TABLE_NAME" is not necessary, because MESSAGE is good enough. I don't
>>> see any difference - and I would to use these variables for error
>>> handling (not for logging) without dependency on current format of
>>> MESSAGE or CONTEXT.
>
>> In my judgement, COLUMN_NAME and TABLE_NAME can be used without having
>> an unreasonable degree of coupling between client and server-side
>> code.
>
> Yeah, I was about to reply in almost exactly those words. Table and
> column names are, almost by definition, part of the shared understanding
> of the client-side and server-side portions of any application, because
> both sides have to manipulate those in order to do anything. However,
> if client-side code were to rely on something like ROUTINE_NAME for
> error processing, it would become closely tied to the *code structure*
> of the server-side functions, which is a bad idea.
>
> Basically the value proposition here is "let's contort the backend code
> in order to support very bad programming practices in applications".
> I'm not attracted by either part of that.

I don't think so it is necessary bad practice.

first - my motivation is related primary for usage in PL/pgSQL.

we can handle exceptions very near to place where exception was
raised. And then I can take same information like ROUTINE_NAME. Later
I can forward exception. A disadvantage of this design is higher
number of subtransactions.

Other design, I talked about it - is based on one relative high
positioned subtransaction, where I can handle lot of types of
exceptions or can raise final exception. I can do same work as in
previous mentioned design but just with one subtransaction. But for
design I need a data. And if is possible in simple form - because it
is better for PL/pgSQL.

>
>> I don't think there should be a TRIGGER_NAME either - I think that we
>> should make interfaces easy to use correctly, and hard to use
>> incorrectly, and a mechanised response to a TRIGGER_NAME seems
>> incorrect. If you think that there should be a trigger name within
>> CONTEXT, there might be a case to be made for that, but I would prefer
>> to have that reviewed separately.
>
> If the calling of a trigger isn't visible in the CONTEXT stack then
> that's something we should address --- but in practice, wouldn't it be
> visible anyway as an ordinary function call? At least if the trigger
> is written in a reasonable PL. If the trigger is written in C, then
> I'm outright against adding any such overhead. I don't think this patch
> should be adding any cycles whatsoever to non-error code paths.
>

visibility in CONTEXT depends on creating and registering error
callbacks - I don't would to change it.

Regards

Pavel
> regards, tom lane