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

From Merlin Moncure
Subject Re: jsonb and nested hstore
Date
Msg-id CAHyXU0wa7eSuERcyq=54Ypxjnpym13syhgq3Rs0YRtkMuhWCiw@mail.gmail.com
Whole thread Raw
In response to Re: jsonb and nested hstore  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Wed, Mar 5, 2014 at 11:19 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Merlin Moncure <mmoncure@gmail.com> writes:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> 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.
>
> That approach abandons every bit of value in an extension, no?
> You certainly don't get to fix bugs outside a core-system release cycle.

That's core vs non core debate.  Just about everyone (including me)
wants json and hstore to live in core -- meaning packaged, shipped,
supported, and documented with the postgresql source code releases.
Only an elite set of broadly useful and popular extensions get that
honor of which json is most certainly one.

Moreover, you give up nothing except the debate/approval issues to get
your code in core.  If you want to release off cycle, you can
certainly do that and enterprising users can simply install the
extension manually (or perhaps via pgxn) instead of via contrib.

BTW,This is yet another thing that becomes impossible if you don't
extension (on top of legacy/backwards compatibility issues and general
bloat which is IMNSHO already a pretty severe situation).

merlin



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: jsonb and nested hstore
Next
From: Tom Lane
Date:
Subject: Re: [PATCH] Negative Transition Aggregate Functions (WIP)