naveen.bysani@gmail.com (chinni) writes:
> Postgres-R is a multi server (write anywhere) replication tool
> which is possibly important for any enterprise if they want to shift
> to postgres.
>
> Did you guys debate on merging it.
I seem to recall there being a licensing issue; Postgres-R uses the
"Spread" communications toolkit that is distributed under a license
reasonably dissimilar to that of PostgreSQL proper.
> As of now They are working on postgres 7.2 and developing
> postgres-R. They plan to do it for 7.4 as well, why not merge these
> things.
Why merge them when the development efforts evidently aren't
integrated? If they were to be merged, this would force the
Postgres-R developers to dance to the PostgreSQL "core team" drum and
vice-versa in order for there to be releases of PostgreSQL.
> Is the postgres team planing to come up with a similar tool
> themselves ?
You might want to look into Slony-I, which is the "first phase" of a
set of replication software. It has not been concluded that Slony-I
will be included in PostgreSQL proper for some of the same reasons
other replication systems have not been integrated in.
Perhaps come 7.6, usage of Slony-I may become so ubiquitous that
everyone will conclude that it's wisest to integrate it in with the
PostgreSQL code base, but that is certainly not known to be true at
this point in time.
Alternatively, it would probably be even more attractive if, come 7.6,
some set of infrastructure analagous to that associated with the
"contrib" modules could allow easy inclusion of projects managed at
GBorg so that it would be easy for people building BSD Ports, Debian
Packages, and such to draw in "modules" alongside PostgreSQL. If that
be the case, then it would make sense to drop all sorts of stuff OUT
of the "core" PostgreSQL sources, as it would be easier to manage them
separately...
--
(format nil "~S@~S" "cbbrowne" "ntlug.org")
http://www.ntlug.org/~cbbrowne/lsf.html
It is impossible to sharpen a pencil with a blunt axe. It is equally
vain to try to do it with ten blunt axes instead.
-- Edsger W. Dijkstra
