Re: RFC: Remove contrib entirely

On 05/28/2015 08:10 PM, Stephen Frost wrote:
> JD,

>>> 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. :)

I knew somebody eventually would ;)

>
>> 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.

Fair enough, although keep in mind we aren't telling people pgAdmin
isn't useful. We are just pushing it out of core. Who runs from source
except developers? Distributions would take care of this for us.

>
>> F.2. auth_delay
>
> Should be a core feature. Having this in a contrib module is silly.
>

+1

>> F.3. auto_explain
>
> Move to extension directory in the repo.

+1

>
>> F.4. btree_gin
>> F.5. btree_gist
>
> Both of these should simply be in core.

+1

>
>> F.6. chkpass
>> F.7. citext
>> F.8. cube
>
>Push out and/or keep it in contrib in repo.
>

Agreed except citext which I think should install by default.

>> F.9. dblink
>
> Move to extension directory in the repo.
>

Agreed.

>> 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.
>

Agreed.

>> 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.

Disagree, hstore should be in core. Rest, fine.

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

Spelling mistake aside ;) agreed

>> F.17. intarray
>
> Move to extension directory in the repo.
>

Agreed

>> F.18. isn
>> F.19. lo
>> F.20. ltree
>> F.21. pageinspect
>
> Move to extension directory in the repo.
>

Except for maybe pageinspect, agreed.

>> F.22. passwordcheck
>
> Should be an in-core capability and not shoved off into an extension.
>

Agreed

>> F.23. pg_buffercache
>
> Pull it into core.
>

Agreed

>> F.24. pgcrypto
>
> Move to extension directory in the repo.
>

Sure.

>> F.25. pg_freespacemap
>
> Should be in core.
>

Agreed.

>> F.26. pg_prewarm
>> F.27. pgrowlocks
>
> Should be in core.
>

With a change to pg_rowlocks, agreed.

>> 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.
>

Agreed just not enabled by default.

>> F.29. pgstattuple
>> F.30. pg_trgm
>
> Should be in core.

Agreed.

>
>> 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)
>

I think they should be in core, not all FDWs of course but file and
postgres are kind of obvious to me.

>> F.32. seg
>> F.33. sepgsql
>
> Move to extension directory in the repo.
>

Agreed.

>> F.34. spi
>
> Maybe pull some into core.. or maybe all, or move to an extension.
>

No opinion.

>> F.35. sslinfo
>
> Should be in core.
>

Agreed.

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

Easy... give it 1 more release. If we get PIVOT, then we don't need it,
if we don't... all the better for us.

>> F.37. tcn
>
> Should be in core, imv, but not a position I hold very strongly.

no opinion

>
>> F.38. test_decoding
>
> Should be in src/test/modules, or maybe some 'examples' dir.
>

agreed

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

Release a "final release" as a pgxn capable extension and rip it out.

>
>> F.40. tsm_system_rows
>> F.41. tsm_system_time
>
> These should be in core.

Agreed

>
>> F.42. unaccent
>
> Move to extension directory in the repo.
>

Agreed

>> 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:
>>

Agreed.

>> 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.
>>

See... we agree on pretty much all of it in principle.

Seriously guys, this particular argument is an argument of "what?". This
is writing on the wall. If Frost and I are in this much agreement... :P

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.