Re: pl/python tracebacks
От | Jan Urbański |
---|---|
Тема | Re: pl/python tracebacks |
Дата | |
Msg-id | 4D7600B7.5040106@wulczer.org обсуждение исходный текст |
Ответ на | Re: pl/python tracebacks (Peter Eisentraut <peter_e@gmx.net>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: