Re: enhanced error fields

Peter Geoghegan <peter@2ndquadrant.com> writes:
> On 29 December 2012 05:04, Pavel Stehule <pavel.stehule@gmail.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 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.
        regards, tom lane