Re: jsonb and nested hstore - Mailing list pgsql-hackers

From Andrew Dunstan
Subject Re: jsonb and nested hstore
Date
Msg-id 530EB434.6060204@dunslane.net
Whole thread Raw
In response to Re: jsonb and nested hstore  (Peter Geoghegan <pg@heroku.com>)
Responses Re: jsonb and nested hstore
Re: jsonb and nested hstore
Re: jsonb and nested hstore
Re: jsonb and nested hstore
List pgsql-hackers
On 02/26/2014 09:43 PM, Peter Geoghegan wrote:
> On Wed, Feb 26, 2014 at 6:29 PM, Robert Haas <robertmhaas@gmail.com> wrote:
>> Why can't this whole thing be shipped as an extension?   It might well
>> be more convenient to have the whole thing packaged as an extension
>> than to have parts of it in core and parts of it not in core.
> That's a good question. I think having everything in contrib would
> make it easier to resolve the disconnect between jsonb and hstore. As
> things stand, there is a parallel set of functions and operators for
> hstore and jsonb, with the former set much larger than the latter. I'm
> not terribly happy with that.
>
>

The jsonb set will get larger as time goes on. I don't think either of 
you are thinking very clearly about how we would do this. Extensions 
can't call each other's code. So the whole notion we have here of 
sharing the tree-ish data representation and a lot of the C API would go 
out the window, unless you want to shoehorn jsonb into hstore. Frankly, 
we'll look silly with json as a core type and the more capable jsonb not.

Not to mention that if at this stage people suddenly decide we should 
change direction on a course that has been very publicly discussed over 
quite a considerable period, and for which Teodor and I and others have 
put in a great deal of work, I at least am going to be extremely annoyed 
(note the characteristic Australian used of massive understatement.)

cheers

andrew




pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Avoiding deeply nested AND/OR trees in the parser
Next
From: Stephen Frost
Date:
Subject: Re: jsonb and nested hstore