On 14/12/10 18:05, David E. Wheeler wrote: > On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote: > >> 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). > > It doesn't turn a returned dictionary into a RECORD? That's what PL/Perl > does, FBOFW.
If the function is declared to return a hstore, it transforms the dictionary to a hstore. IOW: if the return type of a PL/Python function is "known", PL/Python will try to convert the object returned by Python into a Postgres type, according to some rules, that depend on the type. For instance, a if a function is said to return booleans, PL/Python would take the return value of the Python function invocation, cast it to a boolean using Python casting rules and the return a Postgres boolean depending on the result of the cast. If a type is "unknown", PL/Python just casts it to string using Python rules and feeds it to the type's input function. The whole point of this thread is how to make hstore a "known" type. >> 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? Mmm, interesting thought. I don't particularily like it, because mucking with the stringification of a built-in type is a big POLA violation (and there would be other problems as well). And you still have to go through the Python dict -> string -> hstore cycle, instead of cutting the string step out. >> 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. I'm not writing the parser, that's the point. You could provide a pure-Python solution that would do the parsing, but that's fragile, slow and ugly. The idea is: PL/Python notices that the function is supposed to return a hstore. It takes the output of the Python call and uses functions from hstore.so to construct the hstore and return it. Same thing would happen with json. Cheers, Jan -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
