On Mon, Dec 6, 2021 at 6:49 AM Euler Taveira <euler@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 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. 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?
--
Regards,
Dilip Kumar
EnterpriseDB: http://www.enterprisedb.com