On 07/03/11 22:55, Peter Eisentraut wrote: > On mån, 2011-03-07 at 14:19 +0100, Jan Urbański wrote: >> On 07/03/11 14:01, Jan Urbański wrote: >>> On 07/03/11 13:53, Peter Eisentraut wrote: >>>> On sön, 2011-03-06 at 13:14 +0100, Jan Urbański wrote: >>>>> But fixing "raise plpy.Fatal()" >>>>> to actually cause a FATAL is something that should be extracted from >>>>> this patch and committed, even if the full patch does not make it. >>>> >>>> Um, what? I didn't find any details about this in this thread, nor a >>>> test case. >> >>> So this in fact are three separate things, tracebacks, fix for >>> plpy.Fatal and a one-line fix for reporting errors in Python iterators, >>> that as I noticed has a side effect of changing the SQLCODE being raised >>> :( I think I'll just respin the tracebacks patch as 3 separate ones, >>> coming right up. >> >> Respun as three separate patches. Sorry for the confusion. BTW: looks >> like plpy.Fatal behaviour has been broken for quite some time now. > > Committed 1 and 2. > > Your traceback implementation in PLy_elog is now using two errdetail > calls in one ereport call, which doesn't work (first one wins). Please > reconsider that. Also, the comment still talks about the traceback > going into detail.
Gah, will look at this and fix. Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers