On 14/12/10 17:52, Tom Lane wrote: > Peter Eisentraut <pete...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
