On Thu, Jun 4, 2015 at 2:33 PM, Joshua D. Drake <j...@commandprompt.com> wrote: > My argument was (after some preliminary discussion): > > 1. Review contrib > 2. All modules that are "core worthy" install by default > 3. Push all other contrib out into the wild
So above, I said that we keep adding to contrib because "there are some things we want to include in the core distribution without baking them irrevocably into the server" and you said that you weren't arguing with that, but here you're saying you don't want any such things to exist. That doesn't really make any sense. postgres_fdw is a good example. It's "core-worthy" in the sense that it is useful enough to be installed in core, but not everybody may want their database server to have the ability to make network connections at the behest of unprivileged users. Today, they can achieve that by not installing the extension if they don't want users to have access to it. Putting it into core would require us to come up with some new way to control whether that functionality is available or not. That seems like making a lot of work for ourselves for no real benefit. This same argument applies to (at least) dblink and adminpack. > 1. Decrease in code maintenance for core contrib requires very little maintenance, and is often very helpful for judging whether other core changes - e.g. changes to hooks - are working properly. I see no maintenance benefit to removing it; it would probably just make it harder to figure out whether other stuff is broken. And the removal itself would be a ton of work. > 2. Removal of the idea that contrib is a holding queue for not quite up to > snuff code I don't think it's really being used that away any more. > 3. Most extensions don't need to follow the same development pattern that > core does That's not a reason to move things that are already in contrib to somewhere else. At least not that I can see. > 4. Eliminate the EGO of saying "I have a contrib module in core" I've got multiple major features in core. Any ego I may have about my PostgreSQL contributions is not based on pg_prewarm. > 1. 15 years of the same argument (current source: pg_audit) The argument about pg_audit has little to do with contrib. It is primarily about code quality, and secondarily about whether one committer can go do something unliterally when a long list of other committers and contributors have expressed doubts about it. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
