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