Re: RFC: Remove contrib entirely
От | Joshua D. Drake |
---|---|
Тема | Re: RFC: Remove contrib entirely |
Дата | |
Msg-id | 5567CB9E.1030502@commandprompt.com обсуждение исходный текст |
Ответ на | Re: RFC: Remove contrib entirely (Peter Eisentraut <peter_e@gmx.net>) |
Ответы |
Re: RFC: Remove contrib entirely
(Amit Langote <Langote_Amit_f8@lab.ntt.co.jp>)
Re: RFC: Remove contrib entirely (Stephen Frost <sfrost@snowman.net>) |
Список | pgsql-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.
В списке pgsql-hackers по дате отправления:
Следующее
От: Craig RingerДата:
Сообщение: [PATCH] Document that directly callable functions may use fn_extra