> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Dec 13, 2010 at 9:16 PM, Tom Lane <tgl@sss.pgh.pa.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
ahstore could return a dictionary and if it would have only string keys/values, it would be changed into a hstore (and
ifnot, 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/outputtype's OID. It'd be adding a branch to the switches and taking the code from my pyhstore module to parse
thehstore 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-changingGUCs 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)
andvice 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
leadto 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
wesidestep the whole issue.
Also, this would mean that loading an extension module changes the behaviour of already defined functions. Maybe the
parserscould simply go into hstore.so? That is, compile and link in hstore_plpython.o if building --with-python? Not
surehow the packagers will like it (would need 2 hstore packages, right?).
Cheers,
Jan
