Re: jsonb and nested hstore

On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
>> On Wed, Mar 5, 2014 at 10:24 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> > Merlin Moncure <mmoncure(at)gmail(dot)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).
>
> Yeah, from what I gather you're suggesting, that's more-or-less "move it
> all to core", except that all of the actual interface bits end up in an
> extension that has to be installed to use what would have to already be
> there. I don't see that as any kind of improvement.

If you don't then you simply have not been paying attention to the
endless backwards compatibility problems we've faced which are highly
ameliorated in an extension heavy world. Also, you're ignoring the
fact that having an endlessly accreting set of symbols in the public
namespace is not free. Internal C libraries don't have to be
supported and don't have any signficant user facing costs by simply
being there.

merlin