Re: hstores in pl/python

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