On 01/03/11 20:35, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulc...@wulczer.org> writes:
>> Currently the traceback is added to the detail and the original
>> errdetail is preserved. So you'd get the detail line and the traceback
>> below it.
> Hm?  I'm talking about plpython_error_callback() and friends, which
> AFAICS you haven't changed the behavior of at all.  And it would
> certainly be completely inappropriate to do what's said above for
> an errdetail with a non-plpython origin.

Not sure if I understand the problem. PL/Python sets
plpython_error_callback right after entering the function call handler,
so any elog thrown while the function is executing has a "PL/Python
function %s" context message. If plpython calls into SQL with SPI and
something there throws an elog(ERROR) with an errdetail, that detail is
saved inside the exception and a Python error is then thrown. If this
Python error reaches the top of the Python stack, the error reporting
code kicks in, extracts the saved errdetail value from the Python
exception, and then extract the stack trace and also adds it to the

So you end up with a context message saying "PL/Python function %s" and
a detail message with the saved detail (if it's present) *and* the
traceback. The problem is that the name of the function is already in
the traceback, so there's no need for the context *if* there's a
traceback present.

The problem I'm having is technical: since the callback is already set
when the code reaches the traceback-printing stage, you can't really
unset it. AFAICS the elog code calls *all* callbacks from
error_context_stack. So I can't prevent the context message from
appearing. If I make the traceback part of the context as well, it's
just going to appear together with the message from the callback.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to