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

From Marc G. Fournier
Subject Re: contrib vs. gborg/pgfoundry for replication solutions
Date
Msg-id 20040421234409.D32445@ganymede.hub.org
Whole thread Raw
In response to Re: contrib vs. gborg/pgfoundry for replication solutions  (Joe Conway <mail@joeconway.com>)
Responses Re: contrib vs. gborg/pgfoundry for replication solutions
Re: contrib vs. gborg/pgfoundry for replication solutions
List pgsql-hackers
On Wed, 21 Apr 2004, Joe Conway wrote:

> Well, in the case of dblink, consider this:
>
> - It is used by a fair number of people -- questions are answered on the
>    lists at least once a week with "see contrib/dblink".

A fair # of ppl are using erserver/bsd too ... should we add that in too?

> - 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'

> - dblink-type capability should someday make it into the backend, albeit
>    in the form of something compliant to the SQL/MED spec. This is
>    standard functionality in many of the RDBMSs that Postgres users
>    migrate from, and it is needed by enterprise users.

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' ...


----
Marc G. Fournier           Hub.Org Networking Services (http://www.hub.org)
Email: scrappy@hub.org           Yahoo!: yscrappy              ICQ: 7615664


pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Next
From: Jan Wieck
Date:
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions