Re: plpython - Mailing list pgsql-hackers

From Tilo Schwarz
Subject Re: plpython
Date
Msg-id 200309122215.58921.mail@tilo-schwarz.de
Whole thread Raw
In response to plpython  (James Pye <flaw@rhid.com>)
List pgsql-hackers
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


pgsql-hackers by date:

Previous
From: "Thomas T. Thai"
Date:
Subject: Re: Need NetBSD thread tester
Next
From: Christopher Browne
Date:
Subject: Re: Another small bug (pg_autovacuum)