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

From Tom Lane
Subject Re: RFC: Remove contrib entirely
Date
Msg-id 4946.1432935300@sss.pgh.pa.us
Whole thread Raw
In response to Re: RFC: Remove contrib entirely  (Josh Berkus <josh@agliodbs.com>)
Responses Re: RFC: Remove contrib entirely
Re: RFC: Remove contrib entirely
List pgsql-hackers
Josh Berkus <josh@agliodbs.com> writes:
> On 05/29/2015 02:08 PM, Peter Geoghegan wrote:
>> I always liked the idea of organizing contrib along these lines.
>> 
>> I know that I will never be successful in convincing people to remove,
>> say, contrib/isn, which is total garbage, but the next best thing is
>> to categorize it in a way that sets expectations very low.

> Well, contrib/isn is still useful (I use it).  But there's no good
> reason it couldn't be on pgxn.

We already did one round of removal of low-grade contrib items.
Admittedly that was in 2006, and maybe some of the stuff that survived
that cut no longer looks good enough.  But I don't think there's all
that much low-hanging fruit there.

But let's get to the point: the real reason for keeping most of these
contrib modules in the core distribution is that they are essential test
cases for core's extensibility features.  contrib/isn is actually a good
example of that.  It made us realize that extensions that create types
that are physically equivalent to int8 or float8 were broken when we made
those types potentially pass-by-value; we had to add a CREATE TYPE option
to allow that to still work (cf commit 3f936aacc057e4b3).  If contrib/isn
had not been around and been getting built by the buildfarm, we would have
found that out only much later and with much more pain.

You could imagine some other way to address that, like generalizing the
buildfarm so that it can pull in extensions from other source repos for
testing purposes.  But that's going to be a lot of work and I'm not even
real sure we want it --- it'd increase the trust problem for buildfarm
owners quite a bit, for one thing.

I'm not particularly on board with renaming things just to get rid of the
term "contrib".  We have much better things to do with our time.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Steve Kehlet
Date:
Subject: Re: Re: [GENERAL] 9.4.1 -> 9.4.2 problem: could not access status of transaction 1
Next
From: Tom Lane
Date:
Subject: Re: [CORE] postpone next week's release