All,
So there are currently three kinds of things in contrib:
A. Extra commands and tools which aren't considered general enough, or
reliable enough, to be included by default, e.g. pg_standby, pgbench and
vacuumlo.
B. Developer tools, like spi, start-scripts, and oid2name.
C. "Core Extensions", which fall into three further groups:
C1: encryption extensions we can't include in core
for legal reasons (pg_crypto)
C2: example extensions which show useful things about
how to build an extension
C3: Admin extensions which are not core because they carry
risks (e.g. pgstattuple, auto_explain)
C4: Extensions which are generally useful, used, and
maintained with Postgres (e.g. hstore, citext)
So A and B need to stay somewhere in the source distribution. I would
like to see them go into /admin-tools and /developer-tools directories;
I believe that Greg Smith came up with a patch to do just this at
sometime in the past. C2 could also go into /developer-tools, and C3
are really just more admin-tools. C1 would need to stick around as a
special case.
To move C4, you'd have to solve the problem of "how do we turn a former
external extension into a core feature", which nobody yet has solved.
All of this ignores the critical part of this, which is packaging.
Right now packagers ship a "contrib" package which includes everything
in /contrib. Shifting to having any other arrangement is going to
involve working with them and convincing them that a change to packaging
is worthwhile. And then getting the news to our users.
Given that, there needs to be significant benefit to our users in the
change. So, what's the benefit?
--
Josh Berkus
PostgreSQL Experts Inc.
http://pgexperts.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
