Re: RFC: Remove contrib entirely - Mailing list pgsql-hackers

From Andres Freund
Subject Re: RFC: Remove contrib entirely
Date
Msg-id 20150604184146.GJ18006@awork2.anarazel.de
Whole thread Raw
In response to Re: RFC: Remove contrib entirely  ("Joshua D. Drake" <jd@commandprompt.com>)
Responses Re: RFC: Remove contrib entirely  (Andres Freund <andres@anarazel.de>)
List pgsql-hackers
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.



pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: xid wrap / optimize frozen tables?
Next
From: Andres Freund
Date:
Subject: Re: RFC: Remove contrib entirely