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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
