On Mar 1, 2011, at 12:10 PM, Jan Urbański wrote: > 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.
I remember going through a lot of pain getting this done "right" in pg-python[pl/py]. SELECT it_blows_up(); ERROR: function's "main" raised a Python exception CONTEXT: [exception from Python] Traceback (most recent call last): File "public.it_blows_up()", line 13, in main three() File "public.it_blows_up()", line 10, in three return two() File "public.it_blows_up()", line 7, in two return one() File "public.it_blows_up()", line 4, in one raise OverflowError("there's water everywhere") OverflowError: there's water everywhere [public.it_blows_up()] IIRC, I unconditionally print the "[public.it_blows_up()]" part iff it's not an ERROR. If it is an ERROR, I let the traceback rendering part of the code handle it on the PL's entry point exit. It was really tricky to do this because I was rendering the traceback *after* the error_context_stack had been called. -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers