Bruce Momjian <[EMAIL PROTECTED]> writes:Joshua D. Drake wrote:It is not that we don't want to include replication in the base project it is that ERserver does not meet the requirements of what can
be included in the base project. Specifically (I believe) the requirement of Java.
Maybe they will move to C someday.
Well, JDBC requires Java, and it's still in the main distro.
I think the real answer is that until recently, ERserver wasn't open source and we didn't have the option to include it. Now that it is open source, we could think about it. Having looked at the code, I think it's definitely not ready for prime time, but it could get there with some work. When it's of comparable solidity to the base project I'd be in favor of adding it to the base distro.
Unfortunately I don't think it'll get there ever. There is a fundamental design flaw in the system that is not fixable (there are multiple, but this is one of the biggies). That is that eRServer only remembers that a row has been modified, but not what, in what order, not even how often.
The problem is really easy to demonstrate. With a UNIQUE constraint on a column, you change the values of two rows like
A->C
B->A
C->BIf these 3 changes fall into one "snapshot", you have no chance to replicate that. eRServer tries to do
A->B
B->Aand whatever order it tries, you'd need a deferred UNIQUE constraint to get it done, and I don't have the slightest clue how the ever get _that_ implemented.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives?
http://archives.postgresql.org
