Re: jsonb and nested hstore

From: Peter Geoghegan <pg(at)heroku(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Merlin Moncure <mmoncure(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Josh Berkus <josh(at)agliodbs(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Christophe Pettus <xof(at)thebuild(dot)com>, PostgreSQL-development Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: jsonb and nested hstore
Date: 2014-03-05 18:59:37
Message-ID: CAM3SWZSQK0LoLg7uVYwhSx54PBcFd7dkeRLfDp5+JSy78EFd2w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Mar 5, 2014 at 8:30 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 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?
>
> I believe the main thing is the opclasses.

Yes, that's right. A large volume of code currently proposed for
hstore2 is much less valuable than those operators sufficient to
implement the hstore2 opclasses. If you assume that hstore will become
a legacy extension that we won't add anything to (including everything
proposed in any patch posted to this thread), and jsonb will go in
core (which is of course more or less just hstore2 with a few json
extras), the amount of code redundantly shared between core and an
unchanged hstore turns out to not be that bad. I hope to have a
precise answer to just how bad soon.

--
Peter Geoghegan

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-03-05 18:59:45 Re: UNION ALL on partitioned tables won't use indices.
Previous Message Tom Lane 2014-03-05 18:58:13 Re: API change advice: Passing plan invalidation info from the rewriter into the planner?