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

From Joe Conway
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 408745FE.7000100@joeconway.com
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  ("Marc G. Fournier" <scrappy@postgresql.org>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions
List 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 by date:

Previous
From: Tom Lane
Date:
Subject: Re: valgrind errors
Next
From: Karel Zak
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions