Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От scott.marlowe
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id Pine.LNX.4.33.0404211401470.22303-100000@css120.ihs.com
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  ("Joshua D. Drake" <jd@commandprompt.com>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Список pgsql-hackers
I almost agree, but I think things that are being actively developed to 
eventually move into the backend, like autovacuum or slony-I should be in 
contrib.  Things that aren't destined for backend integration should be 
removed though, like pgbench or dblink or whatnot.

On Wed, 21 Apr 2004, Joshua D. Drake wrote:

> Hello,
> 
> My personal opinion is that contrib should be removed entirely. Just 
> have a contrib.txt that says all contrib modules are at pgfoundry or 
> whatever.
> 
> Sincerely,
> 
> Joshua D. Drake
> 
> 
> Jan Wieck wrote:
> 
> > Taking into account that quite a few people have repeatedly stated that 
> > the components in contrib are considered more supported/recommended than 
> > similar solutions found on gborg or any other external site, I suggest 
> > we move the projects dbmirror and dblink to gborg. The rserv contrib 
> > module seems to me to be an early Perl prototype of erserver, nobody is 
> > working on any more. I suggest we drop that entirely.
> > 
> > Comments/alternatives?
> > 
> > 
> > Jan
> > 
> 
> ---------------------------(end of broadcast)---------------------------
> TIP 8: explain analyze is your friend
> 



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions
Следующее
От: Oleg Bartunov
Дата:
Сообщение: Re: contrib vs. gborg/pgfoundry for replication solutions