Re: [HACKERS] removing tsearch2 - Mailing list pgsql-hackers

On Tue, Feb 14, 2017 at 8:37 AM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
> Right; I think we need at least some amount of pgxn buildfarm coverage.
> There probably also needs to be a way to officially bless certain
> distributions. Unless there's a pretty significant need for an official
> extension to be in contrib, it should go into PGXN.

I'm not sure a need-based test is going to be entirely the right
thing.  The advantage of having something in contrib is that the core
developers will maintain it for you.  When things change from release
to release, everything in contrib necessarily gets updated; things on
PGXN or elsewhere only get updated if their owners update them.  There
are several good things about that.  First, it means that people can
rely on the stuff in contrib mostly sticking around for future
releases, except occasionally when we decide to drop a module.
Second, it gives maintainers of external modules examples of what they
need to do to update their code when we change the core APIs.  Third,
it's probably actually more efficient for one person to go sweep
through a large number of modules and fix them all at once than if
those things were all on PGXN with separate owners.  Now, you can
overdo that: I don't want to be responsible for every module on PGXN
or anything close to it.  But on balance I think there's a good case
for shipping a substantial set of modules in contrib.

I think, in general, that we've done a good job increasing the quality
of contrib over time.  Pretty much all of the new stuff we've added is
fairly solid, and we cleaned things up significantly by moving test
code to src/test/modules.  But we've still got some older modules in
contrib whose quality and general usefulness is pretty questionable
IMV: earthdistance, intagg, intarray, isn, and of course the
eternally-deprecated but never-actually-removed xml2.  I'm not in a
hurry to expend a lot of energy removing any of that stuff, and I
think we might be reaching our quota of backward-incompatible changes
for this release, but it's questionable in my mind whether having
those things there works out to a net plus.  There's a lot of good
stuff in contrib, though, and I don't think we should be averse to
adding more in the future.  It shouldn't be just that any random
contrib module somebody writes can get dropped into the core
distribution, but I think we ought to be open to reasonable proposals
to add things there when it makes sense.

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