Horton

Re: pl/python tracebacks

Jan Urbański <wulczer@wulczer.org>

View thread
From: Jan Urbański <wulczer@wulczer.org>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2011-03-07T13:19:46Z
Lists: pgsql-hackers

Attachments

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.

Jan