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
   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


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 
was rendering the traceback *after* the error_context_stack had been called.
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to