Re: contrib vs. gborg/pgfoundry for replication solutions

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
Cc: "Joshua D(dot) Drake" <jd(at)commandprompt(dot)com>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Date: 2004-04-21 19:49:06
Message-ID: 14857.1082576946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

"Marc G. Fournier" <scrappy(at)postgresql(dot)org> writes:
> On Wed, 21 Apr 2004, Tom Lane wrote:
>> "Joshua D. Drake" <jd(at)commandprompt(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Rob Oakley 2004-04-21 19:59:09 PostgreSQL (7.3) on SMB/CIFS Shares on FreeBSD 5.1
Previous Message Joshua D. Drake 2004-04-21 19:47:09 Re: contrib vs. gborg/pgfoundry for replication solutions