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