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.


Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to