On 14/12/10 17:52, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
>> On mån, 2010-12-13 at 08:50 +0100, Jan Urbański wrote:
>>> It would be cool to be able to transparently use hstores as Python
>>> dictionaries and vice versa. It would be easy enough with hstore as a
>>> core type, but with hstore as an addon it's not that easy.
>
>> I have been thinking about this class of problems for a while. I think
>> the proper fix is to have a user-definable mapping between types and
>> languages. It would be another pair of input/output functions,
>> essentially.
>
> Interesting thought, but it still leaves you needing to solve the
> problem of interconnecting two optional addons ...
So I've been thinking about hot these two optional addons could
interact, and here's a sketchy plan:
1) the hstore contrib module when compiling with --with-python generates
a loadable hstore_plpython.so
2) hstore_plpython, when loaded, sets a rendezvous variable that points
to a structure containing two parser functions
3) plpython when converting PG datums to Python objects looks for the
hstore's rendezvous variable and if it finds it, it uses the parsers
Problem: what to do it hstore_plpython gets loaded, but hstore is not
yet loaded. hstore_plpython will want to DirectFunctionCall(hstore_in),
so loading hstore_plpython without loading hstore will result in an
ereport(ERROR, "undefined symbol hstore_in") with an errhint of "please
load hstore first". I could live with that, if no one has a better idea.
If that's OK, I'll go and code it. The rest is dressing on top, which I
would happily skip.
3a) optionally, there's a custom GUC for plpython called
plpython_hstore_as_dict that can be "always", "never" or
"when_available". "always" means that if the rendezvous variable is not
set, you get an ERROR when you pass in a hstore variable. "never" means
that regardless of hstore_plpython loading it gets ignored.
"when_available" is what I described above. The default is still to be
bikeshed. I think we can skip that, as someone loading hstore_plpython
is supposed to know that it will affect plpython functions, end of
story. Also: the hstore parsers would detect if the return value is a
dict and if not, would cast it to text and try to parse it. So if you
were hand-crafting your hstores in plpython before, it will still work,
thus making the compatibility argument moot.
Does that sound acceptable?
Jan