On 2015-06-04 11:33:47 -0700, Joshua D. Drake 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 > > Possibly: > > 1. Have a contrib project that sat outside of core > 2. Push all contrib or some contrib to pgxn (or some other place) > > Because: > > 1. Decrease in code maintenance for core
The modules that aren't going to be in core, hardly cost time, do they? > 2. Removal of the idea that contrib is a holding queue for not quite up to > snuff code I don't think that idea exists widely. > 3. Most extensions don't need to follow the same development pattern that > core does The point is that users want them to follow that. > 4. Eliminate the EGO of saying "I have a contrib module in core" Seriously? > 1. 15 years of the same argument (current source: pg_audit) I don't see getting rid of contrib helping with that. The only change will then be whether something should be in core. And there's stuff that's just very hard to develop out of core; but doesn't necessarily immediately belong into core. E.g. pg_stat_statements is relatively closely tied to things in core. > 2. Helping reduce overall resource need to manage contrib This discussion a significant share of that. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
