Re: RFC: Remove contrib entirely

<p dir="ltr">Le 29 mai 2015 5:33 AM, "Joshua D. Drake" <<a
href="mailto:jd@commandprompt.com">jd@commandprompt.com</a>>a écrit :<br /> ><br /> ><br /> > On 05/28/2015
08:10PM, Stephen Frost wrote:<br /> >><br /> >> JD,<br /> ><br /> ><br /> >>>> This seems
reasonableto me.  It's in line with the recent move from<br /> >>>> contrib to bin.  It'll just be quite a
bitbigger of an undertaking.<br /> >>>> (50 threads to discuss the merits of each module separately?) 
Maybe<br/> >>>> start by picking the top 5 and sort those out.<br /> >>><br /> >>><br />
>>>The thing is, we don't have that many to argue about now, in fact:<br /> >><br /> >><br />
>>Alright, I'll bite. :)<br /> ><br /> ><br /> > I knew somebody eventually would ;)<br /> ><br />
><br/> >><br /> >>> F.1. adminpack<br /> >><br /> >><br /> >> Need it- pgAdmin
can'tsenibly install it or even include it in some<br /> >> way, and it'd be *very* painful to not have it for a
lotof users.<br /> ><p dir="ltr">Painful? The adminpack allows pgadmin to change the config files remotely with a UI
thatdoesn't make it easy to say the least. You may well trash your pg_hba.conf file and not be able to connect again
afterreloading. It also allows you to read your log files remotely... if it only contains UTF8 characters (which
doesn'thappen much with my french customers). And loading a 1GB log file is definitely painful.<p dir="ltr">I would be
ofthe idea it doesn't give much (though it doesn't mean I want it to be dropped), but I'm pretty much telling my
customersto drop it whenever I can.<p dir="ltr">> Fair enough, although keep in mind we aren't telling people
pgAdminisn't useful. We are just pushing it out of core. Who runs from source except developers? Distributions would
takecare of this for us.<br /> ><p dir="ltr">Yeah. The way I see this is that distributions would make packages for
eachextension. And I don't see the difference between doing a<p dir="ltr">yum install postgresql94-contrib<p
dir="ltr">Anda<p dir="ltr">yum install postgresql94-adminpack<p dir="ltr">for example, except I would have to run
various"yum install" commands to install every extensions I need, but this is much better for me than bloating my
systemwith extensions I never use (earthdistance comes to mind for example).<p dir="ltr">FWIW, I don't mind which one
weput in core and which one we put out of core. But I like Joshua's idea of getting rid of contribs and pushing them
outas any other extensions.<p dir="ltr">>>> F.2. auth_delay<br /> >><br /> >><br /> >>
Shouldbe a core feature.  Having this in a contrib module is silly.<br /> >><br /> ><br /> > +1<br />
><br/> >>> F.3. auto_explain<br /> >><br /> >><br /> >> Move to extension directory in
therepo.<br /> ><br /> ><br /> > +1<br /> ><br /> ><br /> >><br /> >>> F.4. btree_gin<br
/>>>> F.5. btree_gist<br /> >><br /> >><br /> >> Both of these should simply be in core.<br
/>><br /> ><br /> > +1<br /> ><br /> ><br /> >><br /> >>> F.6. chkpass<br /> >>>
F.7.citext<br /> >>> F.8. cube<br /> >><br /> >><br /> >> Push out and/or keep it in contrib
inrepo.<br /> >><br /> ><br /> > Agreed except citext which I think should install by default.<br />
><br/> ><br /> ><br /> >>> F.9. dblink<br /> >><br /> >><br /> >> Move to extension
directoryin the repo.<br /> >><br /> ><br /> > Agreed.<br /> ><br /> ><br /> >>> F.10.
dict_int<br/> >>> F.11. dict_xsyn<br /> >><br /> >><br /> >> Looks like these are just
examples? Maybe move to an 'examples'<br /> >> directory, or into src/test/modules, or keep in contrib.<br />
>><br/> ><br /> > Agreed.<br /> ><br /> ><br /> >>> F.12. earthdistance<br /> >><br />
>><br/> >> Depends on cube, so, same as whatever happens there.  I don't think<br /> >>
extensions-in-reposhould depend on contrib modules, as a rule.<br /> >><br /> >>> F.13. file_fdw<br />
>>>F.14. fuzzystrmatch<br /> >>> F.15. hstore<br /> >><br /> >><br /> >> Move to
extensiondirectory in the repo.<br /> ><br /> ><br /> > Disagree, hstore should be in core. Rest, fine.<br />
><br/> ><br /> >><br /> >>> F.16. intagg<br /> >><br /> >><br /> >> Obsolute,
perthe docs.  Push out and deal with the break, or keep it in<br /> >> contrib in repo.<br /> >><br />
><br/> > Spelling mistake aside ;) agreed<br /> ><br /> ><br /> >>> F.17. intarray<br />
>><br/> >><br /> >> Move to extension directory in the repo.<br /> >><br /> ><br /> >
Agreed<br/> ><br /> ><br /> >>> F.18. isn<br /> >>> F.19. lo<br /> >>> F.20. ltree<br
/>>>> F.21. pageinspect<br /> >><br /> >><br /> >> Move to extension directory in the
repo.<br/> >><br /> ><br /> > Except for maybe pageinspect, agreed.<br /> ><br /> ><br />
>>>F.22. passwordcheck<br /> >><br /> >><br /> >> Should be an in-core capability and not
shovedoff into an extension.<br /> >><br /> ><br /> > Agreed<br /> ><br /> ><br /> >>> F.23.
pg_buffercache<br/> >><br /> >><br /> >> Pull it into core.<br /> >><br /> ><br /> >
Agreed<br/> ><br /> ><br /> >>> F.24. pgcrypto<br /> >><br /> >><br /> >> Move to
extensiondirectory in the repo.<br /> >><br /> ><br /> > Sure.<br /> ><br /> ><br /> >>>
F.25.pg_freespacemap<br /> >><br /> >><br /> >> Should be in core.<br /> >><br /> ><br />
>Agreed.<br /> ><br /> ><br /> >>> F.26. pg_prewarm<br /> >>> F.27. pgrowlocks<br />
>><br/> >><br /> >> Should be in core.<br /> >><br /> ><br /> > With a change to
pg_rowlocks,agreed.<br /> ><br /> ><br /> >>> F.28. pg_stat_statements<br /> >><br /> >><br
/>>> I'd actually prefer that this be in core, but I'd be alright with it<br /> >> being in extension
directoryin the repo.<br /> >><br /> ><br /> > Agreed just not enabled by default.<br /> ><br /> ><br
/>>>> F.29. pgstattuple<br /> >>> F.30. pg_trgm<br /> >><br /> >><br /> >> Should
bein core.<br /> ><br /> ><br /> > Agreed.<br /> ><br /> ><br /> >><br /> >>> F.31.
postgres_fdw<br/> >><br /> >><br /> >> Move to extension directory in the repo.<br /> >>
(actually,I'd be fine with both this and file_fdw being included in<br /> >> core..  I'm just not 100% sure how
that'dlook)<br /> >><br /> ><br /> > I think they should be in core, not all FDWs of course but file and
postgresare kind of obvious to me.<br /> ><br /> ><br /> >>> F.32. seg<br /> >>> F.33.
sepgsql<br/> >><br /> >><br /> >> Move to extension directory in the repo.<br /> >><br />
><br/> > Agreed.<br /> ><br /> ><br /> >>> F.34. spi<br /> >><br /> >><br /> >>
Maybepull some into core..  or maybe all, or move to an extension.<br /> >><br /> ><br /> > No opinion.<br
/>><br /> ><br /> >>> F.35. sslinfo<br /> >><br /> >><br /> >> Should be in core.<br
/>>><br /> ><br /> > Agreed.<br /> ><br /> ><br /> >>> F.36. tablefunc<br /> >><br />
>><br/> >> My gut reaction is that it should be in core for crosstab(), but David's<br /> >> talking
aboutimplementing PIVOT, so..<br /> >><br /> ><br /> > Easy... give it 1 more release. If we get PIVOT,
thenwe don't need it, if we don't... all the better for us.<br /> ><br /> ><br /> >>> F.37. tcn<br />
>><br/> >><br /> >> Should be in core, imv, but not a position I hold very strongly.<br /> ><br />
><br/> > no opinion<br /> ><br /> ><br /> >><br /> >>> F.38. test_decoding<br /> >><br
/>>><br /> >> Should be in src/test/modules, or maybe some 'examples' dir.<br /> >><br /> ><br />
>agreed<br /> ><br /> ><br /> ><br /> >>> F.39. tsearch2<br /> >><br /> >><br />
>>I'm inclined to just drop this..  Or we could keep it in contrib in the<br /> >> repo.<br /> ><br />
><br/> > Release a "final release" as a pgxn capable extension and rip it out.<br /> ><br /> ><br />
>><br/> >>> F.40. tsm_system_rows<br /> >>> F.41. tsm_system_time<br /> >><br />
>><br/> >> These should be in core.<br /> ><br /> ><br /> > Agreed<br /> ><br /> ><br />
>><br/> >>> F.42. unaccent<br /> >><br /> >><br /> >> Move to extension directory in
therepo.<br /> >><br /> ><br /> > Agreed<br /> ><br /> ><br /> >>> F.43. uuid-ossp<br />
>><br/> >><br /> >> This one probably deserves its own thread, heh..<br /> >><br />
>>>F.44. xml2<br /> >><br /> >><br /> >> Push it out, or keep it in contrib in repo.<br />
>><br/> >>> Look at these, a lot of them are obvious... just include for goodness sakes:<br />
>>><br/> ><br /> > Agreed.<br /> ><br /> ><br /> >>> pg_trgm has been in contrib for a
decadeof not more. Either rip it<br /> >>> out or include it by default.<br /> >>><br /> >>>
postgres_fdw(by the time we make the change it will be two releases)<br /> >><br /> >><br /> >>
Agreed.<br/> >><br /> >>> sepgsql has no business being in core, it is:<br /> >>><br />
>>>1. An extension<br /> >>> 2. About as linux specific as we can get<br /> >><br />
>><br/> >> Not sure that being platform agnostic has to be a requirement of being<br /> >> in the
repoor being an extension in the repo...  It does need some work<br /> >> though and discussion has recently
startedabout if the sepgsql types<br /> >> defined in the SELinux reference policy should continue to exist or
if<br/> >> they should be changed.  I'm following that discussion with interest.<br /> >><br />
>>>Adminpack:<br /> >>><br /> >>> It is for pgAdmin, give it back or push it into core
proper<br/> >><br /> >><br /> >> I'd keep it in the repo as an extension.  Pushing it out would
just<br/> >> cause lots of trouble for little gain.<br /> >><br /> >>> I just don't think this
wouldbe that hard if we were willing to put<br /> >>> our minds to it.<br /> >>><br /> ><br />
>See... we agree on pretty much all of it in principle.<br /> ><br /> > Seriously guys, this particular
argumentis an argument of "what?". This is writing on the wall. If Frost and I are in this much agreement... :P<br />
><br/> ><br /> > Sincerely,<br /> ><br /> > jD<br /> ><br /> ><br /> > -- <br /> > Command
Prompt,Inc. - <a href="http://www.commandprompt.com/">http://www.commandprompt.com/</a>  503-667-4564<br /> >
PostgreSQLCentered full stack support, consulting and development.<br /> > Announcing "I'm offended" is basically
tellingthe world you can't<br /> > control your own emotions, so everyone else should do it for you.<br /> ><br
/>><br /> > -- <br /> > Sent via pgsql-hackers mailing list (<a
href="mailto:pgsql-hackers@postgresql.org">pgsql-hackers@postgresql.org</a>)<br/> > To make changes to your
subscription:<br/> > <a
href="http://www.postgresql.org/mailpref/pgsql-hackers">http://www.postgresql.org/mailpref/pgsql-hackers</a><br/>