| From: | Peter Eisentraut <peter_e(at)gmx(dot)net> |
|---|---|
| To: | Jan Urbański <wulczer(at)wulczer(dot)org> |
| 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 21:55:52 |
| Message-ID: | 1299534952.874.9.camel@vanquo.pezone.net |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
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.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Peter Eisentraut | 2011-03-07 21:59:38 | Re: Alpha4 release blockers (was Re: wrapping up this CommitFest) |
| Previous Message | Jeff Davis | 2011-03-07 21:51:31 | Re: Parallel make problem with git master |