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.
Yes, my fault for sneaking it here without more introduction than this comment several messages upthread: """ While testing I noticed that this broke "raise plpy.Fatal()" behaviour - it was no longer terminating the backend but just raising an error. That's fixed in this version. This patch also fixes a place where ereport is being used to report Python errors, which leads to losing the original error. Incidentally, this is exactly the issue that made diagnosing this bug: http://postgresql.1045698.n5.nabble.com/Bug-in-plpython-s-Python-Generators-td3230402.html so difficult. """ 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. BTW, it's hard to test if raising plpy.Fatal actually causes a FATAL elog, because that would terminate the backend running the tests, and I though pg_regress treats this as an unconditional error (or am I mistaken?). Jan -- Sent via pgsql-hackers mailing list (firstname.lastname@example.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers