From: | Tilo Schwarz <mail(at)tilo-schwarz(dot)de> |
---|---|
To: | James Pye <flaw(at)rhid(dot)com>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: plpython |
Date: | 2003-09-12 20:15:58 |
Message-ID: | 200309122215.58921.mail@tilo-schwarz.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Manfred Spraul | 2003-09-12 21:14:23 | Re: [PATCHES] Reorganization of spinlock defines |
Previous Message | Peter Eisentraut | 2003-09-12 19:20:48 | Re: Reorganization of spinlock defines |