Re: hstores in pl/python

Поиск
Список
Период
Сортировка
От David E. Wheeler
Тема Re: hstores in pl/python
Дата
Msg-id 71FB716D-CEFF-4AF8-94A0-9210F5647A49@kineticode.com
обсуждение исходный текст
Ответ на Re: hstores in pl/python  (Jan Urbański <wulczer@wulczer.org>)
Список pgsql-hackers
On Dec 14, 2010, at 11:52 AM, Jan Urbański wrote:

> If the function is declared to return a hstore, it transforms the
> dictionary to a hstore.

Oh, right. Duh.

>> 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.

Could you do it with a subclass of Dictionary? I'm thinking only of the params passed to the function here, not
returned.It doesn't matter what the return value stringifies as if you can use functions to do the transformation from
dictto hstore. 

>> 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. 
>
> 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.

Right, that sounds great. No reason why we couldn't support many of these hash-like things, eh? The question then is
justidentifying those types. That would be fantastic for PL/Perl, too. 

Best,

David



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Jan Urbański
Дата:
Сообщение: Re: hstores in pl/python
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Triggered assertion "!(tp.t_data->t_infomask & HEAP_XMAX_INVALID)" in heap_delete() on HEAD [PATCH]