Re: New Contrib Build? - Mailing list pgsql-hackers

From Marc G. Fournier
Subject Re: New Contrib Build?
Date
Msg-id 20050512114156.W6493@ganymede.hub.org
Whole thread Raw
In response to Re: New Contrib Build?  (Andrew Dunstan <andrew@dunslane.net>)
Responses Re: New Contrib Build?  (Andreas Pflug <pgadmin@pse-consulting.de>)
List pgsql-hackers
On Thu, 12 May 2005, Andrew Dunstan wrote:

>
>
> Tom Lane wrote:
>
>> Peter Eisentraut <peter_e@gmx.net> writes:
>> 
>>> Andrew Dunstan wrote:
>>> 
>>>> First, I *really* wish we'd call it something else. Contrib conveys
>>>> "unsupported" to people.
>>>> 
>> 
>> 
>>> And that's exactly what it is supposed to mean.  We say, these modules do 
>>> not necessarily meet our standards with regard to code quality, 
>>> portability, user interfaces, internationalization, documentation, etc. 
>>> There is certainly a lot of good software in contrib and one could in 
>>> individual cases consider moving them out of there, but contrib is what it 
>>> is.
>>> 
>> 
>> Which is as it should be, I think.  Contrib is essentially the "not
>> quite ready for prime time" area.  If it were 100% up to speed then
>> it'd be in the core backend already ... while if we required it to be
>> 100% in advance, then it'd not have gotten out there in the first place.
>> 
>> The real issue seems to be that we have a disconnect between what is
>> presently in contrib and what is on gborg or pgfoundry.  There are
>> certainly many contrib modules that are only there on seniority: if
>> they were submitted today then they'd have gotten put on pgfoundry.
>> But I'm not sure that there's much value in an enforced cleanup.
>> 
>
> I think there probably is.  Too much in there looks just abandoned. On the 
> flip side, I know we're dealing with the pg_autovacuum issue, but we get lots 
> of queries about crypto functions and text search because people don't know 
> they are in contrib.
>
> BTW, I note that the TODO list has these delightfully non-specific items:
>
>   * Move some things from /contrib into main tree
>   * Move some /contrib modules out to their own project sites

contrib was originally meant as a 'staging ground' for stuff to eventually 
go into core *or* just removed from contrib ... its turned into a 'final 
resting ground' ...

Josh's point about 'different categories' is pertinent, except that all 
that should be in contrib is the stuff that is applicable to core, which 
is pretty much the 'datatype' stuff ... I really liked someone's idea of a 
'modules' directory, that stuff like dbsize, earthdistance, tsearch2, etc 
could go under, but stuff like admintools should be on pgfoundry ...

 ----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: Server instrumentation for 8.1
Next
From: Tom Lane
Date:
Subject: Re: implementing NOTIFY with message parameter