Re: contrib vs. gborg/pgfoundry for replication solutions

From: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: "Marc G(dot) Fournier" <scrappy(at)postgresql(dot)org>, Jan Wieck <JanWieck(at)Yahoo(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: contrib vs. gborg/pgfoundry for replication solutions
Date: 2004-04-22 02:47:11
Message-ID: 20040421234409.D32445@ganymede.hub.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(at)hub(dot)org Yahoo!: yscrappy ICQ: 7615664

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jan Wieck 2004-04-22 02:54:54 Re: contrib vs. gborg/pgfoundry for replication solutions
Previous Message Bruce Momjian 2004-04-22 02:44:33 Re: contrib vs. gborg/pgfoundry for replication solutions