From: | Jan Urbański <wulczer(at)wulczer(dot)org> |
---|---|
To: | "David E(dot) Wheeler" <david(at)kineticode(dot)com> |
Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Robert Haas <robertmhaas(at)gmail(dot)com>, Postgres - Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: hstores in pl/python |
Date: | 2010-12-14 19:52:30 |
Message-ID: | 4D07CAFE.4010401@wulczer.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | David E. Wheeler | 2010-12-14 19:59:38 | Re: hstores in pl/python |
Previous Message | Simon Riggs | 2010-12-14 19:48:00 | Re: ALTER TABLE ... REPLACE WITH |