Re: [Postgres-xc-developers] Replicated update and delete

[Mason S. <ms...@tr...>]

>
>>>  I'm afraid it takes long effort to fix all the influences of this
>>> change.   How do you think about this?    As I noted, approach C has good
>>> point.   The issue is how long it takes.   With approach B, we can easily
>>> change this handling to approach C.   I'd like to have you opinion on this.
>>>
>>
>> It seems unnecessary if the table already has a primary key or unique
>> index. Anyway, approach C is the approach that I originally took with
>> GridSQL/Stado, adding something called xrowid, but we later disabled it by
>> default.
>>
>
> Was there any other reason of disabling it other than code simplicity and
> maintainability?
>

Yes. We could have saved time and worked on other things.


>
>
>>  In hindsight I would have saved the trouble and not implemented it to
>> keep the code simpler and easier to maintain, and just left it up to the
>> user to use a key.
>>
>> To summarize, I would go with B.
>>
>
> What is your stance on the fact that going with option B makes us backward
> in-compatible?
>

Right now the situation is not good. Better to make it backward
incompatible than to have data issues. I also don't believe the user base
is too big as of yet to cause too many people headaches.

Also, other RDBMSs require primary keys for replication. IIRC even Slony
requires one.


-- 
Mason Sharp

TransLattice - http://www.translattice.com
Distributed and Clustered Database Solutions