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

From Marc G. Fournier
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 20040421163008.Q32445@ganymede.hub.org
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: contrib vs. gborg/pgfoundry for replication solutions  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
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.
>
> However the replication modules don't seem to have such a linkage,
> so I have no objection to moving them out.

Agreed ... but I also think that something like pg_autovacuum should be
moved to gborg ... there seems to be alot of activity on fixing bugs in it
that most ppl won't see until they upgrade to the next release, even
though those fixes would be pertinent/useful to their current
implementation ... begin able to download/install pg_autovacuum 1.1 would
definitely be a good thing, when it was considered stable enoguh for a
release ...

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

----
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: "Dave Page"
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: "Joshua D. Drake"
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions