On tis, 2010-12-14 at 11:52 -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@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,...'