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