|From:||Jan Urbański <wulczer(at)wulczer(dot)org>|
|To:||Peter Eisentraut <peter_e(at)gmx(dot)net>|
|Cc:||Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org>|
|Subject:||Re: pl/python tracebacks|
|Views:||Raw Message | Whole Thread | Download mbox | Resend email|
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.
|Next Message||Yeb Havinga||2011-03-07 13:20:08||Re: Sync Rep v19|
|Previous Message||Jan Urbański||2011-03-07 13:01:35||Re: pl/python tracebacks|