Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> 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->B
If these 3 changes fall into one "snapshot", you have no chance to
replicate that. eRServer tries to do
A->B
B->A
and 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. #
#================================================== JanWieck@Yahoo.com #
