Re: hstores in pl/python
От | David E. Wheeler |
---|---|
Тема | Re: hstores in pl/python |
Дата | |
Msg-id | 81DE1AD1-4B10-44FD-87B2-9C91852431B7@kineticode.com обсуждение исходный текст |
Ответ на | Re: hstores in pl/python (Jan Urbański <wulczer@wulczer.org>) |
Ответы |
Re: hstores in pl/python
|
Список | pgsql-hackers |
On Dec 13, 2010, at 11:37 PM, Jan Urbański wrote: > A function with a hstore parameter called x would get a Python dictionary as its input. A function said to be returninga 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). See the README for pyhstore and take out pyhstore.parse/serialize. It doesn't turn a returned dictionary into a RECORD? That's what PL/Perl does, FBOFW. > There is already type conversion infrastructure in plpython, in the form of two functions with a switch that takes theinput/output type's OID. It'd be adding a branch to the switches and taking the code from my pyhstore module to parsethe hstore to and fro. > > Then there's the compatibility argument. Hstores used to be passed as strings, so it will break user code. I hate behaviour-changingGUCs as much as anyone, but it seems the only option... Can you overload the stringification of a dictionary to return the hstore string representation? > 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 leadto 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 thenwe 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'thave to write a parser. Best, David
В списке pgsql-hackers по дате отправления: