Re: contrib vs. gborg/pgfoundry for replication solutions - Mailing list pgsql-hackers

From Tom Lane
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 14857.1082576946@sss.pgh.pa.us
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
List pgsql-hackers
"Marc G. Fournier" <scrappy@postgresql.org> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <jd@commandprompt.com> writes:
>>> My personal opinion is that contrib should be removed entirely.
>> 
>> That's not real workable for code that is tightly tied to the backend,
>> such as the various GIST index extensions presently in contrib.  It's
>> just easier to maintain that code when it's in with the backend.

> tsearch, I believe, is maintained somewhere else already, no?  same with
> tsearch2?

No, those guys are exactly the sort of backend-dependent code I'm
thinking of.  Teodor just recently made a GIST API change that affected
both the core backend and tsearch (as well as the other GIST modules in
contrib).  With separate distribution trees that would've been a lot
more painful to do.

I think the long-term plan for tsearch2, at least, should be full
integration rather than separation ...
        regards, tom lane


pgsql-hackers by date:

Previous
From: Jan Wieck
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: "scott.marlowe"
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions