Re: contrib vs. gborg/pgfoundry for replication solutions
От | Marc G. Fournier |
---|---|
Тема | Re: contrib vs. gborg/pgfoundry for replication solutions |
Дата | |
Msg-id | 20040421163008.Q32445@ganymede.hub.org обсуждение исходный текст |
Ответ на | Re: contrib vs. gborg/pgfoundry for replication solutions (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: contrib vs. gborg/pgfoundry for replication solutions
Re: contrib vs. gborg/pgfoundry for replication solutions |
Список | 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 по дате отправления: