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 errdetail. 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. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
