Re: jsonb and nested hstore

* Merlin Moncure (mmoncure(at)gmail(dot)com) wrote:
> On Wed, Mar 5, 2014 at 11:44 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> > 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.

I don't see why we can't do exactly what you're suggesting in core.
This whole thread is about doing exactly that, in fact, which is why
we're talking about 'jsonb' instead of just 'json'. I agree that we
don't push too hard to remove things from core, but it's not like we've
had a whole ton of success kicking things out of -contrib either.

> > 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.

Yeah, but I much prefer how things end up in pg_catalog rather than
public or individual schemas.

> > 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.

But we actually *aren't* free to change or delete them- which is what I
was getting at. Certainly, in back-branches we regularly worry about
breaking things for users of C functions, and there is some
consideration for them even in major version changes.

Thanks,

Stephen