All data types should map to the same python object types as they did before, so int32->PyInt, int64->PyLong, numeric->PyFloat, etc.
The conversion routines are slightly different, eg int32 is initialized via PyInt_FromLong() instead of first converting the integer to a string then calling PyInt_FromString, this is a little faster, but shouldn't result in differences, if anything this should be more correct. Previously numeric->string->PyFloat_FromString, now numeric->double->PyFloat_FromDouble, which makes use of postgres numeric->double routines rather than python string->double routines, and it is conceivable that there are precision variations between the two. My own feeling on the matter is that PyFloat is the wrong mapping for numeric, but I didn't want to muddy this patch by changing that. The main compatibility issue is with Python Strings that contain embedded nulls. Conversion to bytea will now work correctly and build the bytea using PyString_FromStringAndSize instead of PyString_FromString. Other datatypes will now error if the PyString contains embedded nulls, previously they would silently truncate. Thanks for the comments, Caleb On 5/27/09 3:11 AM, "Peter Eisentraut" <pete...@gmx.net> wrote: On Wednesday 27 May 2009 02:07:33 Caleb Welton wrote: > Patch for plpythonu > > Primary motivation of the attached patch is to support handling bytea > conversion allowing for embedded nulls, which in turn allows for supporting > the marshal module. > > Secondary motivation is slightly improved performance for conversion > routines of basic datatypes that have simple mappings between > postgres/python. > > Primary design is to change the conversion routines from being based on > cstrings to datums, eg: PLyBool_FromString(const char *) => > PLyBool_FromBool(PLyDatumToOb, Datum); Makes sense; please add it to the next commit fest. Are there any compatibility implications, that is, do any of the conversions work differently from before (except when they were broken before, as in the case of bytea)?
