Jan Urbański <wulczer@wulczer.org> writes:
> I looked into putting the tracebacks in the context field, but IMHO it
> doesn't really play out nice. PL/Python uses a errcontext callback to
> populate the context field, so the reduntant information (the name of
> the function) is always there. If that callback would be removed, the
> context information will not appear in plpy.warning output, which I
> think would be bad.
> So: the context is currently put unconditionally into every elog
> message, which I think is good. In case of errors, the traceback already
> includes the procedure name (because of how Python tracebacks are
> typically formatted), which makes the traceback contain redundant
> information to the context field. Replacing the context field with the
> traceback is difficult, because it is populated by the error context
> callback.
> After thinking about it more I believe that the context field should
> keep on being a one line indication of which function the message comes
> from (and that's how it's done in PL/pgSQL for instance), and the detail
> field should be used for the details of the message, like the traceback
> that comes with it, and that's what the attached patch does.
To me, none of those arguments seem good. Traceback is the sort of
thing that belongs in errcontext, and arbitarily deciding that plpython
isn't going to play by the rules doesn't sit well here. I agree that
what you are showing is redundant with the current errcontext printout,
but the solution for that is to change the errcontext printout, not to
add redundant and inappropriate errdetail.
An example of the reasoning for this is the situation where a plpython
function calls back into SQL, and something there throws an ereport
(which might include an errdetail). It would be useful to include the
Python traceback in the errcontext stack, since there might be multiple
levels of Python function call within what PG sees as just a "plpython
function". But you can't get there with this approach.
regards, tom lane
