On Mon, Dec 6, 2021 at 12:06 PM Dilip Kumar <dilipbal...@gmail.com> wrote: > > On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira <eu...@eulerto.com> wrote: > > > > On Fri, Dec 3, 2021, at 8:12 PM, Euler Taveira wrote: > > > > PS> I will update the commit message in the next version. I barely changed > > the > > documentation to reflect the current behavior. I probably missed some > > changes > > but I will fix in the next version. > > > > I realized that I forgot to mention a few things about the UPDATE behavior. > > Regardless of 0003, we need to define which tuple will be used to evaluate > > the > > row filter for UPDATEs. We already discussed it circa [1]. This current > > version > > chooses *new* tuple. Is it the best choice? > > But with 0003, we are using both the tuple for evaluating the row > filter, so instead of fixing 0001, why we don't just merge 0003 with > 0001? >
I agree that would be better than coming up with an entirely new approach especially when the current approach is discussed and agreed upon. > I mean eventually, 0003 is doing what is the agreed behavior, > i.e. if just OLD is matching the filter then convert the UPDATE to > DELETE OTOH if only new is matching the filter then convert the UPDATE > to INSERT. +1. > Do you think that even we merge 0001 and 0003 then also > there is an open issue regarding which row to select for the filter? > I think eventually we should merge 0001 and 0003 to avoid any sort of data consistency but it is better to keep them separate for the purpose of a review at this stage. If I am not wrong that still needs bug-fix we are discussing it as part of CF entry [1], right? If so, isn't it better to review that bug-fix patch and the 0003 patch being discussed here [2] to avoid missing any already reported issues in this thread? [1] - https://commitfest.postgresql.org/36/3162/ [2] - https://www.postgresql.org/message-id/CAHut%2BPtJnnM8MYQDf7xCyFAp13U_0Ya2dv-UQeFD%3DghixFLZiw%40mail.gmail.com -- With Regards, Amit Kapila.