Re: Conflict Detection and Resolution

On Mon, Sep 30, 2024 at 2:27 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Fri, Sep 27, 2024 at 1:00 PM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
...
> >
> > 13. General - ordering of conflict_type.
> >
> > nit - Instead of just some apparent random order, let's put each
> > insert/update/delete conflict type in alphabetical order, so at least
> > users can find them where they would expect to find them.
>
> This ordering was decided while implementing the 'conflict-detection
> and logging' patch and thus perhaps should be maintained as same. The
> ordering is insert, update and delete (different variants of these).
> Please see a comment on it in [1] (comment #2).
>
> [1]:https://www.postgresql.org/message-id/TYAPR01MB569224262F44875973FAF344F5B22%40TYAPR01MB5692.jpnprd01.prod.outlook.com
>

+1 for order insert/update/delete.

My issue was only about the order *within* each of those variants.
e.g. I think it should be alphabetical:

CURRENT
insert_exists
update_origin_differs
update_exists
update_missing
delete_origin_differs
delete_missing

SUGGESTED
insert_exists
update_exists
update_missing
update_origin_differs
delete_missing
delete_origin_differs

>
> > ~~~
> >
> > 14.
> > 99. General - ordering of conflict_resolver
> >
> > nit - ditto. Let's name these in alphabetical order. IMO it makes more
> > sense than the current random ordering.
> >
>
> I feel ordering of resolvers should be same as that of conflict
> types, i.e. resolvers of insert variants first, then update variants,
> then delete variants. But would like to know what others think on
> this.
>

Resolvers in v14 were documented in this random order:
error
skip
apply_remote
keep_local
apply_or_skip
apply_or_error

Some of these are resolvers for different conflicts. How can you order
these as "resolvers for insert" followed by "resolvers for update"
followed by "resolvers for delete" without it all still appearing in
random order?

======
Kind Regards,
Peter Smith.
Fujitsu Australia