> The reason the earlier attempts at Postgres-R didn't ever make it out
> of testing was precisely, I argue, because there just wasn't an
> interface for the rest of the PostgreSQL project (maybe not
> interested in replication) to keep stable. So merely keeping up with
> the pace of change in the core code turned into a significant
> undertaking. Those are cycles stolen from the more useful work of
> making the replication code work better.
Actually I don't buy this argument. The only major change in
*postgresql* that has slowed down Replicator is the move from
users/groups to roles. We added a feature in the internal 1.6 release to
replicate users/groups.
We are currently behind because of things that have really nothing to do
with PostgreSQL and more to do with reworking an evolutionary code base
to be more manageable.
I don't know much (anything) about Postgres-R but my guess is that the
only major change that would have effected that project in recent years
would have been two phase commit and that is only if they chose to take
advantage of it.
Sincerely,
Joshua D. Drake