James Pye writes:
> Type conversion
>
> plpython's current type conversion implementation appears to be dependent
> on strings as the common format. This is fine, but not very extensible as
> is, unless you don't mind explicitly parsing strings inside each function
> that takes an unsupported data type. I was thinking that a better solution
> would be creating a python object type inside the database. Thus allowing
> users to write casts to and from non-standard or unimplemented data types
> with little difficulty(well, maybe some :). This would allow conversion in
> an extensible way, which doesn't require modification to plpython. Storage
> could be easily achieved by pickling the object. Another thought would be
> to just pass valid PyObject pointers in and out of conversion procedures,
> effectively disallowing storage(outside the process in which the object was
> created in), unless it is possible to have a persistent storage mechanism
> that makes it possible to go through pickle?.?..(yeah, I'm new to pgsql
> dev).
As a first step I would be already be happy, if plpython would use more Python
datatypes, for example:
- currently, a Point (or a box, polygon, etc.) is returned as a string
"(0, 1)"
instead of a Python tuple (or list)
(0, 1)
- the same holds for arrays: instead of getting an array as string (which I
have to parse into a python list), I would like to get a python list in the
first place.
Regards,
Tilo
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
