Re: RFC: Remove contrib entirely

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:

F.1. adminpack
F.2. auth_delay
F.3. auto_explain
F.4. btree_gin
F.5. btree_gist
F.6. chkpass
F.7. citext
F.8. cube
F.9. dblink
F.10. dict_int
F.11. dict_xsyn
F.12. earthdistance
F.13. file_fdw
F.14. fuzzystrmatch
F.15. hstore
F.16. intagg
F.17. intarray
F.18. isn
F.19. lo
F.20. ltree
F.21. pageinspect
F.22. passwordcheck
F.23. pg_buffercache
F.24. pgcrypto
F.25. pg_freespacemap
F.26. pg_prewarm
F.27. pgrowlocks
F.28. pg_stat_statements
F.29. pgstattuple
F.30. pg_trgm
F.31. postgres_fdw
F.32. seg
F.33. sepgsql
F.34. spi
F.35. sslinfo
F.36. tablefunc
F.37. tcn
F.38. test_decoding
F.39. tsearch2
F.40. tsm_system_rows
F.41. tsm_system_time
F.42. unaccent
F.43. uuid-ossp
F.44. xml2

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)

sepgsql has no business being in core, it is:

1. An extension
2. About as linux specific as we can get

Adminpack:

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

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.

Ego... is not a good reason.

Of course the other option:

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.

Sincerely,

jD

>
>
>

--
Command Prompt, Inc. - http://www.commandprompt.com/ 503-667-4564
PostgreSQL Centered full stack support, consulting and development.
Announcing "I'm offended" is basically telling the world you can't
control your own emotions, so everyone else should do it for you.