| 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 |
| Date: | 2011-03-07 13:19:46 |
| Message-ID: | 4D74DB72.3050802@wulczer.org |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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
| Attachment | Content-Type | Size |
|---|---|---|
| 0003-Add-Python-tracebacks-to-error-messages.patch | text/x-patch | 0 bytes |
| From | Date | Subject | |
|---|---|---|---|
| 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 |