On Nov 28, 2006, at 10:18 AM, Markus Schiltknecht wrote:
>> Well, part of the problem is there isn't much to say to code that I
>> can't look at. I can play with it on the live CD, but so far the
>> source isn't on the web page at postgres-r.org, which is the only
>> source I know for it. This makes the whole matter trickier for
>> potential adopters, because it's basically a black box.
>
> Very understandable. I'm trying to find ways to open source
> Postgres-R.
Related to that, and your comment about people not using Postgres-
R... I think it's going to be very, very hard to get people to
seriously consider using Postgres-R while it's essentially a fork of
the community code, with little/no visibility into what changes have
been made and how they could affect data stored in the database.
Contrast this with Slony, where there are no back-end changes and the
trigger code (which is essentially the only thing that touches your
live data) is readily visible just via \df+. That makes it very easy
for people to convince themselves that Slony is unlikely to hose
their data. Of course at this point there's enough people using Slony
that that's no longer a concern, but back when it was introduced it
would have been.
Given the nature of Postgres-R, I suppose there's no real way people
could become comfortable without looking at most/all of the code,
since it does tie pretty deeply into the backend. But that's one way
that having published hooks would help; if you could at least put the
code that touches the guts of the database and the source data out in
the open, people might be more willing to give Postgres-R a try.
You also mentioned putting IPC in the backend, since it's something
that you need. I think breaking something as complex as replication
into smaller chunks that can stand on their own is a great idea.
Oracle's replication does this, and I wish Slony would. Having access
to the queuing/communications mechanism that the Slony folks have
built would be very useful. So I'd definitely encourage making
subsets of Postgres-R functionality available, and promoting them via
pgFoundry.
--
Jim Nasby jim@nasby.net
EnterpriseDB http://enterprisedb.com 512.569.9461 (cell)
