Re: pl/python tracebacks

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

In response to

Responses

Browse pgsql-hackers by date

  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