Re: contrib vs. gborg/pgfoundry for replication solutions

Поиск
Список
Период
Сортировка
От Joe Conway
Тема Re: contrib vs. gborg/pgfoundry for replication solutions
Дата
Msg-id 408745FE.7000100@joeconway.com
обсуждение исходный текст
Ответ на Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Ответы Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Список pgsql-hackers
Marc G. Fournier wrote:
> On Wed, 21 Apr 2004, Joe Conway wrote:
>>- It is dependent on backend code to the extent that it cannot be built
>>   outside of the contrib folder, unless some backend code is duplicated
>>   in the external project. It also has no build system of its own.
> 
> k, so this one falls under 'too lazy to build a proper build system'

No, I don't call that lazy, I call it smart. It makes use (reuse) of a 
part of Postgres (the contrib build system) that is among its strengths. 
Is it your goal to make it harder for people to write their own C 
language functions? It makes no sense whatsoever to expect everyone who 
wants to extend Postgres to develop their own build system. I'd call 
that alot of duplicated effort -- effort better spent more productively.

> dblink isn't an integrated replication solution, it is a standalone one
> ... to date, I have not seen one replication solution that solves all the
> issues, and unless someone comes up with the be all, end all replication
> solution, none of them should be considered 'part of the backend' ...

No one (including me) has ever claimed it is any kind of a replication 
system. It is completely different functionality.

Joe


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

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