Re: enhanced error fields

2012/12/29 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Peter Eisentraut <peter_e(at)gmx(dot)net> writes:
>> On 12/28/12 2:03 PM, Peter Geoghegan wrote:
>>> None of the Python built-in exception types have this kind of
>>> information available from fields or anything.
>
>> Sure, OSError has a filename attribute (which I'm sure is qualified by a
>> directory name if necessary), SyntaxError has filename, lineno, etc.
>
> No no no ... that's completely unrelated. Those fields report
> information about the user-visible object that the error is about.
>
> The point Peter G is making is that reporting the source of the error is
> like having the kernel report the name of the function inside the kernel
> that threw the error. Or perhaps the name of the kernel source file
> containing that function.
>
> Now, these things are quite useful *to a kernel developer* who's trying
> to debug a problem involving an error report. But they're pretty
> useless to an application developer, and certainly any application
> developer who relied on such information to control his error handling
> code would receive no sympathy when (not if) a new kernel version broke
> it.
>
> In the same way, the filename/lineno stuff that we include in ereports
> is sometimes useful to Postgres developers --- but it is very hard to
> see a reason why application code would do anything else with it except
> possibly print it for human reference.

I wrote exactly this - our filename, funcname is not useful for PL
application developers

>
> And, in the same way, a CONTEXT traceback is sometimes useful for
> debugging a collection of server-side functions --- but it's hard to see
> any client-side code using that information in a mechanized way, at
> least not while respecting a sane degree of separation between
> server-side and client-side code.

again - it is reason why I propose ROUTINE_NAME and TRIGGER_NAME - it
can be useful for some use cases, where developer should to handle
exception when they coming from known functions/triggers and he would
to raise exception, when it was raised elsewhere. Is possible working
with CONTEXT, but it needs little bit more work and situation is very
similar to fields COLUMN_NAME, where I can parse message and I can get
this information. But then it depends on message format.

>
> 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.

Second question - what should be context is important. I am thinking
so standard and implementation in other databases is relative clean -
it is name of custom routine, that doesn't handle exception. Moving to
pg - it is name of routine on the top on error callback stack, because
builtin functions doesn't set it - I don't need on top of CONTEX -
div_int or other name of builtin function - but I need there function
foo(b): a := 10/b.

other point - theoretically I can get ROUTINE_NAME from CONTEXT, but I
cannot get TRIGGER_NAME - this information is lost.

Regards

Pavel

>
> regards, tom lane