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

From Andrew Dunstan
Subject Re: jsonb and nested hstore
Date
Msg-id 53176131.6020205@dunslane.net
Whole thread Raw
In response to Re: jsonb and nested hstore  (Bruce Momjian <bruce@momjian.us>)
List pgsql-hackers
On 03/05/2014 12:01 PM, Bruce Momjian wrote:
> On Wed, Mar  5, 2014 at 11:53:31AM -0500, Andrew Dunstan wrote:
>>> I think we also have to break out how much of the feeling that JSONB is
>>> not ready is because of problems with the core/contrib split, and how
>>> much of it is because of the type itself.  I am suggesting that
>>> core/contrib split problems are not symptomatic of data type problems,
>>> and if address/address the core/contrib split issue, the data type might
>>> be just fine.
>>>
>>
>> Splitting out jsonb to an extension is going to be moderately
>> painful. The json and jsonb functions share some code that's not
>> exposed (and probably shouldn't be). It's not likely to be less
>> painful than implementing the hstore GIN/GIST ops for jsonb, I
>> suspect the reverse.
> OK, that's good information.  So we have JSONB which ties to a core
> type, JSON, _and_ to a contrib module, hstore.  No wonder it is so
> complex.


Well, "ties to" is a loose term. It's hstore in these patches that 
depends on jsonb - necessarily since we can't have core code depend on 
an extension.


> I am warming up to the idea of moving hstore internals into core,
> sharing that with JSONB, and having contrib/hstore just call the core
> functions when defining its data type.
>


Right, at least the parts they need in common. That's how I'd handle the 
GIN/GIST ops, for example.

cheers

andrew



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)
Next
From: Andres Freund
Date:
Subject: Re: parallel pg_dump causes assertion failure in HEAD