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

From Merlin Moncure
Subject Re: jsonb and nested hstore
Date
Msg-id CAHyXU0wPLyxywG7J38dGVA=7xPj=+D8kXJmZ=XR7OHEGjN6m_g@mail.gmail.com
Whole thread Raw
In response to Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: jsonb and nested hstore  (Stephen Frost <sfrost@snowman.net>)
Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>>>> *All* non-sql standard types ought to be in extensions in an ideal world.
>
> While there's certainly much to be said for the idea that jsonb should be
> an extension, I don't think we have the technology to package it as a
> *separate* extension; it'd have to be included in the hstore extension.

I disagree with that.  The shared C bits can live inside the core
system and the SQL level hooks and extension specific behaviors could
live in an extension.  AFAICT moving jsonb to extension is mostly a
function of migrating the hard coded SQL hooks out to an extension
(I'm probably oversimplifying though).

> Just out of curiosity, exactly what features are missing from jsonb
> today that are available with hstore?  How long would it take to
> copy-and-paste all that code, if someone were to decide to do the
> work instead of argue about it?

Basically opclasses, operators (particularly search operators) and
functions/operators to manipulate the hstore in place.  Personally I'm
not inclined to copy/paste the code.  I'd also like to see this stuff
committed, and don't want to hold up the patch for that unless it's
determined for other reasons (and by other people) this is the only
reasonable path for 9.4.

merlin



pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: jsonb and nested hstore
Next
From: Stephen Frost
Date:
Subject: Re: jsonb and nested hstore