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
returninga 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
theinput/output type's OID. It'd be adding a branch to the switches and taking the code from my pyhstore module to
parsethe 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-changingGUCs 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
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
thenwe 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'thave to write a parser.
Best,
David