Re: Oid registry

Поиск
Список
Период
Сортировка
От Hannu Krosing
Тема Re: Oid registry
Дата
Msg-id 50623D91.7080808@krosing.net
обсуждение исходный текст
Ответ на Re: Oid registry  (Heikki Linnakangas <hlinnakangas@vmware.com>)
Список pgsql-hackers
On 09/25/2012 12:13 PM, Heikki Linnakangas wrote:
> On 25.09.2012 12:19, Hitoshi Harada wrote:
>> On Tue, Sep 25, 2012 at 1:06 AM, Simon Riggs<simon@2ndquadrant.com>  
>> wrote:
>>> On 24 September 2012 21:26, Andrew Dunstan<andrew@dunslane.net>  wrote:
>>>> Well, an obvious case is how record_to_json handles fields. If it 
>>>> knows
>>>> nothing about the type all it can do is output the string value. That
>>>> doesn't work well for types such as hstore. If it could reliably 
>>>> recognize a
>>>> field as an hstore it might well be able to do lots better.
>
> I'm not at all familiar with record_to_json or the json datatype, but 
> wouldn't it be appropriate to create a cast from hstore to json to 
> handle that case?
>
> That brings us to another question: should the cast be part of the 
> hstore extension, or json? (json is built-in, but imagine for a moment 
> that it was an extension, too, so that there was a choice). IIRC 
> someone started a discussion on that recently on pgsql-hackers, but I 
> don't think there was any conclusion on that.
>
I would make the CAST part of both extensions and try to do it so, that 
if the "other" type does not exists then it will not be created. So the 
extension that comes later will be creating it.

The most sensible extension would be to make it into a 3rd extension 
which depends on both json and hstore being installed

CREATE EXTENSION hstore_to_json_cast;
>
> - Heikki
>
>




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

Предыдущее
От: John R Pierce
Дата:
Сообщение: Re: Switching timeline over streaming replication
Следующее
От: Hannu Krosing
Дата:
Сообщение: Re: Oid registry