Re: process crash when a plpython function returns - Mailing list pgsql-hackers

From Tino Wildenhain
Subject Re: process crash when a plpython function returns
Date
Msg-id 1119108448.1183.71.camel@Andrea.peacock.de
Whole thread Raw
In response to Re: process crash when a plpython function returns unicode  (Michael Fuhr <mike@fuhr.org>)
Responses Re: process crash when a plpython function returns unicode
List pgsql-hackers
Am Samstag, den 18.06.2005, 08:41 -0600 schrieb Michael Fuhr:
> I've moved this thread from pgsql-bugs to pgsql-hackers; here are
> the original messages:
> 
> http://archives.postgresql.org/pgsql-bugs/2005-06/msg00105.php
> http://archives.postgresql.org/pgsql-bugs/2005-06/msg00107.php
> 
> As I mentioned in my followup to the bug report, a simple fix would
> appear to be to check for a NULL return value from PyObject_Str()
> before calling PyString_AsString() at the following location:
> 
>     /* Lines 776-77 in plpython.c */
>     plrv_so = PyObject_Str(plrv);
>     plrv_sc = PyString_AsString(plrv_so);
> 
> I was going to submit a patch, but I don't know enough about the
> Python API or how Python and PostgreSQL handle Unicode to know
> whether adding that simple check is the appropriate solution (I was
> planning to raise an error if PyObject_Str() returned NULL).  Can
> anybody think of a better fix?

raise error would be a correct solution since this is what
python does in this case:

http://docs.python.org/api/exceptions.html

also in this context it would be helpful
if sys.defaultencoding would be set to
the database encoding so strings get encoded
to utf-8 when postgres works in unicode mode
rather then the default encoding of ascii.
This could avoid most of the PyObject_Str()
exeptions in the first place.






pgsql-hackers by date:

Previous
From: Tino Wildenhain
Date:
Subject: Re: [PATCHES] default database creation with initdb
Next
From: Tom Lane
Date:
Subject: pg_locks view versus prepared transactions