Re: RFC: Remove contrib entirely

JD,

* Joshua D. Drake (jd@commandprompt.com) wrote:
> On 05/28/2015 06:50 PM, Peter Eisentraut wrote:
> >On 5/28/15 3:35 PM, Stephen Frost wrote:
> >>What we would need for this is an 'extensions' directory, or similar,
> >>and a clear definition of what the requirements are around getting into
> >>it are.  With that, we could decide for each module currently in contrib
> >>if it should go into the 'extensions' directory.  I'm not sure that we
> >>would necessairly have to remove the contrib module or any modules which
> >>are deemed to not be appropriate for the 'extensions' directory.
> >
> >This seems reasonable to me.  It's in line with the recent move from
> >contrib to bin.  It'll just be quite a bit bigger of an undertaking.
> >(50 threads to discuss the merits of each module separately?)  Maybe
> >start by picking the top 5 and sort those out.
>
> The thing is, we don't have that many to argue about now, in fact:

Alright, I'll bite. :)

> F.1. adminpack

Need it- pgAdmin can't senibly install it or even include it in some
way, and it'd be *very* painful to not have it for a lot of users.

> F.2. auth_delay

Should be a core feature.  Having this in a contrib module is silly.

> F.3. auto_explain

Move to extension directory in the repo.

> F.4. btree_gin
> F.5. btree_gist

Both of these should simply be in core.

> F.6. chkpass
> F.7. citext
> F.8. cube

Push out and/or keep it in contrib in repo.

> F.9. dblink

Move to extension directory in the repo.

> F.10. dict_int
> F.11. dict_xsyn

Looks like these are just examples?  Maybe move to an 'examples'
directory, or into src/test/modules, or keep in contrib.

> F.12. earthdistance

Depends on cube, so, same as whatever happens there.  I don't think
extensions-in-repo should depend on contrib modules, as a rule.

> F.13. file_fdw
> F.14. fuzzystrmatch
> F.15. hstore

Move to extension directory in the repo.

> F.16. intagg

Obsolute, per the docs.  Push out and deal with the break, or keep it in
contrib in repo.

> F.17. intarray

Move to extension directory in the repo.

> F.18. isn
> F.19. lo
> F.20. ltree
> F.21. pageinspect

Move to extension directory in the repo.

> F.22. passwordcheck

Should be an in-core capability and not shoved off into an extension.

> F.23. pg_buffercache

Pull it into core.

> F.24. pgcrypto

Move to extension directory in the repo.

> F.25. pg_freespacemap

Should be in core.

> F.26. pg_prewarm
> F.27. pgrowlocks

Should be in core.

> F.28. pg_stat_statements

I'd actually prefer that this be in core, but I'd be alright with it
being in extension directory in the repo.

> F.29. pgstattuple
> F.30. pg_trgm

Should be in core.

> F.31. postgres_fdw

Move to extension directory in the repo.
(actually, I'd be fine with both this and file_fdw being included in
core..  I'm just not 100% sure how that'd look)

> F.32. seg
> F.33. sepgsql

Move to extension directory in the repo.

> F.34. spi

Maybe pull some into core..  or maybe all, or move to an extension.

> F.35. sslinfo

Should be in core.

> F.36. tablefunc

My gut reaction is that it should be in core for crosstab(), but David's
talking about implementing PIVOT, so..

> F.37. tcn

Should be in core, imv, but not a position I hold very strongly.

> F.38. test_decoding

Should be in src/test/modules, or maybe some 'examples' dir.

> F.39. tsearch2

I'm inclined to just drop this..  Or we could keep it in contrib in the
repo.

> F.40. tsm_system_rows
> F.41. tsm_system_time

These should be in core.

> F.42. unaccent

Move to extension directory in the repo.

> F.43. uuid-ossp

This one probably deserves its own thread, heh..

> F.44. xml2

Push it out, or keep it in contrib in repo.

> Look at these, a lot of them are obvious... just include for goodness sakes:
>
> pg_trgm has been in contrib for a decade of not more. Either rip it
> out or include it by default.
>
> postgres_fdw (by the time we make the change it will be two releases)

Agreed.

> sepgsql has no business being in core, it is:
>
> 1. An extension
> 2. About as linux specific as we can get

Not sure that being platform agnostic has to be a requirement of being
in the repo or being an extension in the repo...  It does need some work
though and discussion has recently started about if the sepgsql types
defined in the SELinux reference policy should continue to exist or if
they should be changed.  I'm following that discussion with interest.

> Adminpack:
>
> It is for pgAdmin, give it back or push it into core proper

I'd keep it in the repo as an extension.  Pushing it out would just
cause lots of trouble for little gain.

> I just don't think this would be that hard if we were willing to put
> our minds to it.
>
> Or.. another way:
>
> Nobody has yet to provide an argument as to why we need contrib when
> we have a fully functioning extension capability.

pg_stat_statements is perhaps one of the best reasons.  Not something
that we necessairly want to force on everyone who installs PG
(presumably the additional shared memory and performance impact is an
issue for some people...  though I'm not sure I agree, though it's been
a while since that discussion and perhaps the impact looks like less
from a distance), but a capability that we absolutely want to have.

Not sure if we want the FDWs to be installed by default...  I had been
thinking there would be an issue with that at first, but the more I
consider it, the more I'm agreeing with you that we should just pull in
both postgres_fdw and file_fdw.

Still, there are extensions which we'll want to have because they simply
can't be included in core for one reason or another, they're very useful
bits of code, and we're willing and eager to maintain them moving
forward.

One of the big questions which will arise out of this though is- how do
we describe contrib vs. this set of extensions?  Do we treat security
issues in the 'new' contrib differently?  Do we only leave things which
are examples or are deprecated in the 'new' contrib?  I'm presuming that
the items which end up in 'extensions' are more formally considered part
of the project and therefore held to the overall project standard (as
contrib is now being, even though it clearly wasn't always that way).

> Freeze contrib. What is in there now, is all there will ever be in
> there and the goal is to slowly reduce it to the point that it
> doesn't matter.

I don't particularly like this option.
Thanks!
    Stephen