From: | Peter Smith <smithpb2250(at)gmail(dot)com> |
---|---|
To: | shveta malik <shveta(dot)malik(at)gmail(dot)com> |
Cc: | Nisha Moond <nisha(dot)moond412(at)gmail(dot)com>, vignesh C <vignesh21(at)gmail(dot)com>, Ajin Cherian <itsajin(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Ashutosh Bapat <ashutosh(dot)bapat(dot)oss(at)gmail(dot)com>, Jan Wieck <jan(at)wi3ck(dot)info>, Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>, "Zhijie Hou (Fujitsu)" <houzj(dot)fnst(at)fujitsu(dot)com> |
Subject: | Re: Conflict Detection and Resolution |
Date: | 2024-09-30 09:25:00 |
Message-ID: | CAHut+PtohfVFXKM10eWLw8PwVQrX=U_kjgG-JLsok8PwCB9zsw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Sep 30, 2024 at 4:29 PM shveta malik <shveta(dot)malik(at)gmail(dot)com> wrote:
>
> On Mon, Sep 30, 2024 at 11:04 AM Peter Smith <smithpb2250(at)gmail(dot)com> wrote:
> >
> > 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:
> > >
> > > > ~~~
> > > >
> > > > 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
> >
>
> Yes, these should be changed.
>
> > 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?
>
> I was thinking of ordering them like this:
>
> apply_remote: applicable to insert_exists, update_exists,
> update_origin_differ, delete_origin_differ
> keep_local: applicable to insert_exists,
> update_exists, update_origin_differ, delete_origin_differ
> apply_or_skip: applicable to update_missing
> apply_or_error : applicable to update_missing
> skip: applicable to update_missing and
> delete_missing
> error: applicable to all.
>
> i.e. in order of how they are applicable to conflict_types starting
> from insert_exists till delete_origin_differ (i.e. reading
> ConflictTypeResolverMap, from left to right and then top to bottom).
> Except I have kept 'error' at the end instead of keeping it after
> 'keep_local' as the former makes more sense there.
>
This proves my point because, without your complicated explanation to
accompany it, the final order (below) just looks random to me:
apply_remote
keep_local
apply_or_skip
apply_or_error
skip
error
Unless there is some compelling reason to do it differently, I still
prefer A-Z (the KISS principle).
======
Kind Regards,
Peter Smith.
Fujitsu Australia
From | Date | Subject | |
---|---|---|---|
Next Message | Daniel Gustafsson | 2024-09-30 09:40:29 | Re: ACL_MAINTAIN, Lack of comment content |
Previous Message | Yugo NAGATA | 2024-09-30 09:22:16 | Re: Doc: typo in config.sgml |