From: Joshua D. Drake <jd@commandprompt.com>
To: Peter Eisentraut <peter_e@gmx.net>
To: Stephen Frost <sfrost@snowman.net>
Cc: pgsql-hackers <pgsql-hackers@postgresql.org>
Subject: Re: RFC: Remove contrib entirely
Date: Thu, 28 May 2015 19:14:54 -0700
Message-ID: <5567CB9E.1030502@commandprompt.com> (raw)
In-Reply-To: <5567C5EB.3070703@gmx.net>
References: <55674016.80005@commandprompt.com>
<20150528193556.GH26667@tamriel.snowman.net>
<5567C5EB.3070703@gmx.net>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-hackers@postgresql.org
Cc: jd@commandprompt.com, peter_e@gmx.net, sfrost@snowman.net
Subject: Re: RFC: Remove contrib entirely
In-Reply-To: <5567CB9E.1030502@commandprompt.com>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox