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.
Jan
