Re: RFC: Remove contrib entirely

On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake <jd(at)commandprompt(dot)com> wrote:
> My argument was (after some preliminary discussion):
>
> 1. Review contrib
> 2. All modules that are "core worthy" install by default
> 3. Push all other contrib out into the wild

So above, I said that we keep adding to contrib because "there are
some things we want to include in the core distribution without baking
them irrevocably into the server" and you said that you weren't
arguing with that, but here you're saying you don't want any such
things to exist. That doesn't really make any sense.

postgres_fdw is a good example. It's "core-worthy" in the sense that
it is useful enough to be installed in core, but not everybody may
want their database server to have the ability to make network
connections at the behest of unprivileged users. Today, they can
achieve that by not installing the extension if they don't want users
to have access to it. Putting it into core would require us to come
up with some new way to control whether that functionality is
available or not. That seems like making a lot of work for ourselves
for no real benefit.

This same argument applies to (at least) dblink and adminpack.

> 1. Decrease in code maintenance for core

contrib requires very little maintenance, and is often very helpful
for judging whether other core changes - e.g. changes to hooks - are
working properly. I see no maintenance benefit to removing it; it
would probably just make it harder to figure out whether other stuff
is broken. And the removal itself would be a ton of work.

> 2. Removal of the idea that contrib is a holding queue for not quite up to
> snuff code

I don't think it's really being used that away any more.

> 3. Most extensions don't need to follow the same development pattern that
> core does

That's not a reason to move things that are already in contrib to
somewhere else. At least not that I can see.

> 4. Eliminate the EGO of saying "I have a contrib module in core"

I've got multiple major features in core. Any ego I may have about my
PostgreSQL contributions is not based on pg_prewarm.

> 1. 15 years of the same argument (current source: pg_audit)

The argument about pg_audit has little to do with contrib. It is
primarily about code quality, and secondarily about whether one
committer can go do something unliterally when a long list of other
committers and contributors have expressed doubts about it.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company