On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote:
> Peter Eisentraut <pete...@gmx.net> writes:
> > On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
> >> It would be cool to be able to transparently use hstores as Python
> >> dictionaries and vice versa. It would be easy enough with hstore as a
> >> core type, but with hstore as an addon it's not that easy.
> 
> > I have been thinking about this class of problems for a while.  I think
> > the proper fix is to have a user-definable mapping between types and
> > languages.  It would be another pair of input/output functions,
> > essentially.
> 
> Interesting thought, but it still leaves you needing to solve the
> problem of interconnecting two optional addons ...

First you create the language and the type (in any order), and then you
create an additional SQL-level designation that connects the two.

In fact, the SQL standard contains something very similar for connecting
user-defined types to host languages.  So adapting that syntax a little,
it could work like this:

CREATE LANGUAGE plpython;

CREATE FUNCTION ...
...
CREATE TYPE hstore ...;

CREATE FUNCTION hstore_to_plpython(hstore) RETURNS internal ...
CREATE FUNCTION plpython_to_hstore(internal) RETURNS plpython ...

CREATE TRANSFORMS FOR hstore (TO plpython WITH hstore_to_plpython, FROM
plpython WITH plpython_to_hstore);


A shorter term solution that avoids creating a whole lot of SQL
infrastructure might be to write out the same transform specification
using a configuration variable, for example

plpython.transforms = 
'hstore:public.hstore_to_plpython:public.plpython_to_hstore,...'



-- 
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to