Re: pl/python tracebacks
Jan Urbański <wulczer@wulczer.org>
From: Jan Urbański <wulczer@wulczer.org>
To: Peter Eisentraut <peter_e@gmx.net>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Postgres - Hackers <pgsql-hackers@postgresql.org>
Date: 2011-03-06T12:14:48Z
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