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
|
Список | 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 по дате отправления: