On Wed, Nov 10, 2010 at 6:39 PM, David E. Wheeler <david@kineticode.com> wrote:
> On Nov 10, 2010, at 3:17 PM, Tom Lane wrote:
>> We've been calling it "contrib" for a dozen years, so that name is
>> pretty well baked in by now. IMO renaming it is pointless and will
>> accomplish little beyond creating confusion and making back-patches
>> harder.
>
> *Shrug*. Just change the name in the docs, then. It's currently "Additional Supplied Modules". Maybe just change that
to"Additional Supplied Extensions" or, even better, "Core Extensions"?
I don't see any value to that change at all. Additional Supplied
Modules is a fine name. If there's a problem here, it's with the name
"contrib", but I don't see that there's enough value in changing that
to be worth the hassle. I think the big hurdle with contrib isn't
that it's called "contrib" but that it's not part of the core server
and, in many cases, enabling a contrib module means editing
postgresql.conf and bouncing the server. Of course, there are
certainly SOME people who wouldn't mind editing postgresql.conf and
bouncing the server but are scared off by the name contrib, but I
suspect the hassle-factor is the larger issue by a substantial margin.
>> (And no, don't you dare breathe a word about git making that
>> all automagically better. I have enough back-patching experience with
>> git by now to be unimpressed; in fact, I notice that its rename-tracking
>> feature falls over entirely when trying to back-patch further than 8.3.
>> Apparently there's some hardwired limit on the number of files it can
>> cope with.)
>
> How often do you have to back-patch contrib, anyway?
[rhaas pgsql]$ git log --format=oneline `git merge-base REL9_0_STABLE
master`..REL9_0_STABLE | wc -l 247
[rhaas pgsql]$ git log --format=oneline `git merge-base REL9_0_STABLE
master`..REL9_0_STABLE contrib | wc -l 20
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company