Re: pl/python tracebacks - Mailing list pgsql-hackers

From Jan Urbański
Subject Re: pl/python tracebacks
Date
Msg-id 4D737AB8.50608@wulczer.org
Whole thread Raw
In response to Re: pl/python tracebacks  (Jan Urbański <wulczer@wulczer.org>)
Responses Re: pl/python tracebacks
List 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


pgsql-hackers by date:

Previous
From: kris@shannon.id.au
Date:
Subject: Re: Perl 5.12 complains about ecpg parser-hacking scripts
Next
From: Magnus Hagander
Date:
Subject: default pg_hba vs replication