Re: jsonb and nested hstore

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

* 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. Doing that to
everyone who uses hstore, just because it's an extension, doesn't make
it acceptable. On this thread we're already argueing about exactly that
issue and how to avoid breaking things for those users were we to move
hstore into core.

> 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. As I
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, clearly, anything released would have to be
supported and if the extension is calling into a C interface then we'd
have to support that interface for that extension *and anyone else who
uses it*. We don't get to say "oh, this C function can only be used by
extensions we bless." We already worry less about breaking backwards
compatibility for C-level functions across PG major versions, but
that's true for both in-core hooks and extensions.

Thanks,

Stephen

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Erik Rijkers 2014-03-05 17:57:05 decoding typos...
Previous Message Alvaro Herrera 2014-03-05 17:43:44 Re: API change advice: Passing plan invalidation info from the rewriter into the planner?