Re: jsonb and nested hstore

Поиск
Список
Период
Сортировка
От Stephen Frost
Тема Re: jsonb and nested hstore
Дата
Msg-id 20140305174406.GX12995@tamriel.snowman.net
обсуждение исходный текст
Ответ на Re: jsonb and nested hstore  (Merlin Moncure <mmoncure@gmail.com>)
Ответы Re: jsonb and nested hstore  (Merlin Moncure <mmoncure@gmail.com>)
Список pgsql-hackers
* Merlin Moncure (mmoncure@gmail.com) wrote:
> On Wed, Mar 5, 2014 at 10:43 AM, Stephen Frost <sfrost@snowman.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

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: parallel pg_dump causes assertion failure in HEAD
Следующее
От: Alvaro Herrera
Дата:
Сообщение: Re: API change advice: Passing plan invalidation info from the rewriter into the planner?