Re: Oid registry - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Oid registry
Date
Msg-id 50623D91.7080808@krosing.net
Whole thread Raw
In response to Re: Oid registry  (Heikki Linnakangas <hlinnakangas@vmware.com>)
List 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 by date:

Previous
From: John R Pierce
Date:
Subject: Re: Switching timeline over streaming replication
Next
From: Hannu Krosing
Date:
Subject: Re: Oid registry