Re: RFC: Remove contrib entirely

On Fri, May 29, 2015 at 10:30 AM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> That work will be much less if we simply split what's in contrib now
> into extension and contrib directories, as it's still all one source
> repo to the packagers. If we punt things out (unless they're being
> formally deprecated/removed) to another repo somewhere, then the
> packagers are going to have to deal with new source repos and related
> complexity. I'm not saying that's a horrible thing and it might make
> sense in some cases, but generally it's a lot easier to go from one
> soruce package to a bunch of binary ones than from lots of tiny source
> packages to lots of tiny packages.
>
> The versioning aspect of this does come into play though, as having
> everything with one relatively slow versioning cycle (on the order of
> months) is actually keeping the load on the packagers down. Lots of
> little releases, all at different times, from lots of different source
> packages, would increase the workload.

These are all good points.

> I'm not sure where I ultimately come down on the question about in-repo
> vs. out-of-repo. My gut feeling is that if the community is willing to
> continue maintaining contrib modules, then that's ultimately a good
> thing and many of them are relatively low-maintenance anyway. Having a
> high barrier to entry for new modules looks a bit odd, given the
> definition of contrib, but would be more understandable with a proper
> 'extensions' directory. Of course, we'd have to collectivly agree that
> we feel comfortable with a lower barrier for contrib that what is being
> done now, if the distinction is going to have any meaning.

I don't agree. It may make sense to keep some stuff in contrib that
is not great code or not really that useful just for historical
reasons. But if we accept every extension with the quality of, say,
contrib/isn into the core distribution, or core distribution is going
to be huge and bloated with crap.

I'd like to point out that we've already done some significant cleanup
of contrib - some things got moved to src/test/modules, and other
stuff to src/bin. So what's in that directory is already a lot more
homogenous than it was a few years ago. Pretty much everything in
there is a loadable module, and if it does something SQL-visible, it's
packaged as an extension. The only exceptions are oid2name,
pg_standby, start-scripts, and vacuumlo. For a directory with >60
things in it, that's pretty good.

I don't think it's very practical to talk about getting rid of contrib
when we reliably add to it in every release:

9.1 added auth_delay, dummy_seclabel, file_fdw, pg_test_fsync, and sepgsql
9.2 added pg_test_timing and tcn
9.3 added pg_xlogdump, postgres_fdw, and worker_spi
9.4 added pg_prewarm, test_decoding, and test_shm_mq
9.5 added hstore_plperl, hstore_plpython, ltree_plpython,
tsm_system_rows, and tsm_system_time

I haven't really gotten familiar with the 9.5 stuff, but most of that
earlier stuff was, uh, pretty good stuff. We wouldn't have been
better off rejecting it, and we wouldn't have been better off putting
it into the main tree.

Any individual person who looks at contrib will no doubt see a fairly
high percentage of stuff they don't care about. Given that part of
the charter of contrib is to hold things that we don't want to put in
the core product for one reason or another, that is to be expected.
But every single one of those 18 contrib modules we've added in the
last 5 years was something that someone cared deeply about, many of
them get real use, and we're just sticking our head in the sand if we
think that's not going to keep happening.

For what it's worth, I also don't particularly support renaming
contrib. I don't really see that it buys us enough to justify the
hassle it will cause. One thing that may be worth doing yet is
separating the code that is just intended as a POC (like worker_spi,
auth_delay and test_decoding) from the stuff that you are really
intended to run in production (like tcn and hstore). But that
distinction is fuzzier than you might think, because while auth_delay
was intended as a POC, I've subsequently heard rumors of it being used
in production with satisfactory results. It's very easy to get the
idea that you know "what PostgreSQL users use" but usually that tends
to mean "what I use" and the community is broad enough that those
things are Not The Same.

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