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-06 12:14:48 |
Message-ID: | 4D737AB8.50608@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 02/03/11 22:28, Jan Urbański wrote:
> On 01/03/11 22:12, Peter Eisentraut wrote:
>> On tis, 2011-03-01 at 21:10 +0100, Jan Urbański wrote:
>>> So you end up with a context message saying "PL/Python function %s"
>>> and a detail message with the saved detail (if it's present) *and* the
>>> traceback. The problem is that the name of the function is already in
>>> the traceback, so there's no need for the context *if* there's a
>>> traceback present.
>>
>> I wouldn't actually worry about that bit of redundancy so much. Getting
>> proper context for nested calls is much more important.
>
> Here's another version that puts tracebacks in the context field.
>
> I did some tests with the attached test script, calling various of the
> functions defined there and the error messages more or less made sense
> (or at least were not worse than before).
I realized I did not update the patch state in the CF app when I added
this version, so I flipped it back to Ready for Committer now.
Tracebacks are a nice-to-have, so if we decide to drop this one due to
time constraints, I'd understand that. 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.
Cheers,
Jan
From | Date | Subject | |
---|---|---|---|
Next Message | Fujii Masao | 2011-03-06 14:10:51 | Re: Replication server timeout patch |
Previous Message | kris | 2011-03-06 11:54:55 | Re: Perl 5.12 complains about ecpg parser-hacking scripts |