Re: PL/Python debugging - line numbers

OK, I figured some things out. Lines numbers are shown through PL/Python
if it is a syntax error, but not for a runtime error. I'm not sure if
this is because plpython.c only returns a partial stack trace, or what.
The 6 year old TODO list doesn't mention this (but does mention that
array argument support is "almost done").

As a workaround, I found that the traceback module for Python 2.4+ can
supply meaningful information. It does require a try/except block. Here
is an example that will have a runtime exception, and print details of
the stack trace:

CREATE OR REPLACE FUNCTION boo(ar1 text)
  RETURNS text AS
$BODY$
import traceback

if False:
    loc = ar1 # this never happens
#return loc # uncomment to test a runtime error without line number
shown in PL/Python
try:
    return loc
except:
    plpy.error(traceback.format_exc())
$BODY$ LANGUAGE 'plpythonu' VOLATILE;

The error message is ugly, but has useful info:

mydb=# select boo('ha');
ERROR:  ('Traceback (most recent call last):\n  File "<string>", line 9,
in __plpython_procedure_boo_96665\nUnboundLocalError: local variable
\'loc\' referenced before assignment\n',)

The actual error is on line 8 (not 9), which is a bit odd. Perhaps there
is a "import plpy" inserted somewhere internally.

I noticed that the messages through PL/Python are all tuples with length
1, like this: ("my message",). Why? This doesn't print to text too nicely.

- Mike

Mike Toews wrote:
> Hi,
>
> Debugging PL/Python isn't as easy as with PL/pgSQL, as it appears I
> can't see line numbers where errors occur. For example:
>
> ERROR:  plpython: function "evaluate_something" failed
> DETAIL:  <type 'exceptions.TypeError'>: sequence index must be
> integer, not 'str'
>
> The location of this type of exception is difficult to spot out in 366
> lines of code. Is there a way to report where the error occurred? I'm
> using 8.3.7 via apt-get on Ubuntu Hardy LTS. I see the same message on
> the server using pgsql and in pgAdmin III on a different machine. I've
> tried using such options as "set client_min_messages to debug;" but
> this doesn't change the details of the error.
>
> Thanks,
>
> -Mike
>
>