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
