Re: jsonb and nested hstore

On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> * Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
>> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
>> > 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.
>
> We have backwards compatibility "problems" because we don't want to
> *break* things for people. Moving things into extensions doesn't
> magically fix that- if you break something in a backwards-incompatible
> way then you're going to cause a lot of grief for people.

It doesn't magically fix it, but at least provides a way forward. If
the function you want to modify is in an extension 'foo', you get to
put your new stuff in 'foo2' extension. That way your users do not
have to adjust all the code you would have broken. Perhaps for
in-core extensions you offer the old one in contrib for a while until
a reasonable amount of time passes then move it out to pgxn. This is
a vastly better system than the choices we have now, which is A. break
code or B. do nothing.

>> 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.
>
> I *really* hate how extensions end up getting dumped into the "public"
> schema and I'm not a big fan for having huge search_paths either.

At least with extensions you have control over this.

> mentioned earlier- I'm also not advocating that everything be put into
> core. I don't follow what you mean by "Internal C libraries don't have
> to be supported" because,

I mean, we are free to change them or delete them. They do not come
with the legacy that user facing API comes. They also do not bloat
the public namespace.

merlin