Re: hstores in pl/python

> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> It seems like what we need at this point is a detailed, non-arm-waving
> design for what Jan would do in pl/python if hstore were in core.  Then
> we can look at it and see exactly what we'd lose from keeping hstore out
> of core and then decide whether it's worth pulling in.

A function with a hstore parameter called x would get a Python dictionary as its input. A function said to be returning a hstore could return a dictionary and if it would have only string keys/values, it would be changed into a hstore (and if not, throw an ERROR). See the README for pyhstore and take out pyhstore.parse/serialize.

There is already type conversion infrastructure in plpython, in the form of two functions with a switch that takes the input/output type's OID. It'd be adding a branch to the switches and taking the code from my pyhstore module to parse the hstore to and fro.

Then there's the compatibility argument. Hstores used to be passed as strings, so it will break user code. I hate behaviour-changing GUCs as much as anyone, but it seems the only option...

> We should also consider the JSON alternative that was muttered about
> upthread.  There's more than one way to hash a hash ...

JSON, when it gets there, can work the same, no problem. JSON params are made available as Python dicts (albeit nested) and vice versa.

How about going the other way around? Hstore would produce hstore_plpython.so apart from hstore.so, if compiling with --with-python. Loading hstore_plpython would register parser functions for hstores in plpython. Additionally this could lead to hstore_plperl in the future etc.

We would need to design some infrastructure for using such hooks in plpython (and in embedded PLs in general) but then we sidestep the whole issue.

Also, this would mean that loading an extension module changes the behaviour of already defined functions. Maybe the parsers could simply go into hstore.so? That is, compile and link in hstore_plpython.o if building --with-python? Not sure how the packagers will like it (would need 2 hstore packages, right?).

Cheers,
Jan