On Fri, Apr 4, 2025 at 10:41 AM Peter Smith <smithpb2...@gmail.com> wrote: > > My point is, if it is deemed useful for a user to know if a *single* > conflict was caused by an INSERT or by an UPDATE, then why is it not > equally useful to know if *multiple* conflicts were caused by an > INSERT or by an UPDATE? >
The reason is that users can resolve single insert_exists or update_exists by using last_update_wins kind of resolution strategy either manually or automatically (in the future, after we get that patch committed). The same may not be true for multiple rows case or at least it won't be as simple the case as for single row, one may need to consider removing multiple rows which can lead to data inconsistency, so we are planning an ERROR as the default resolution startegy. This could be the reason that even BDR has a single conflict_type for this case [1][2]. I don't deny the possibility that in the future, one comes up with a case where separate conflict types for these makes sense, and at that time, we can consider adding more conflict types, but for now, there is no solid case for it that is why we kept a single conflict type. [1] - https://www.enterprisedb.com/docs/pgd/4/bdr/conflicts/#insert-operations-that-violate-multiple-unique-constraints [2] - https://www.enterprisedb.com/docs/pgd/4/bdr/conflicts/#update-operations-that-violate-multiple-unique-constraints -- With Regards, Amit Kapila.
