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.
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
