Re: hstores in pl/python

On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote:

> 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.

It doesn't turn a returned dictionary into a RECORD? That's what PL/Perl does, FBOFW.

> 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...

Can you overload the stringification of a dictionary to return the hstore string representation?

> 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.

It would be better if there was some core support for the hash/ditionary/hstore/json/whatever data type, so that you didn't have to write a parser.

Best,

David