On 01/03/11 20:15, Tom Lane wrote:
> =?UTF-8?B?SmFuIFVyYmHFhHNraQ==?= <wulc...@wulczer.org> writes:
>> 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.

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.

But OK, since there are more voices in favour of putting tracebacks in
the context field, I'll keep on looking for a solution.


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

Reply via email to