On Wed, Jul 14, 2021, at 11:48 AM, Dilip Kumar wrote: > On Wed, Jul 14, 2021 at 8:04 PM Tomas Vondra > <tomas.von...@enterprisedb.com> wrote: > > > > > Perhaps the best way forward is to stick to the approach that INSERT > > uses new, DELETE uses old and UPDATE works as DELETE+INSERT (probably), > > and leave anything fancier (like being able to reference both versions > > of the row) for a future patch. > > If UPDATE works as DELETE+ INSERT, does that mean both the OLD row and > the NEW row should satisfy the filter, then only it will be sent? > That means if we insert a row that is not satisfying the condition > (which is not sent to the subscriber) and later if we update that row > and change the values such that the modified value matches the filter > then we will not send it because only the NEW row is satisfying the > condition but OLD row doesn't. I am just trying to understand your > idea. Or you are saying that in this case, we will not send anything > for the OLD row as it was not satisfying the condition but the > modified row will be sent as an INSERT operation because this is > satisfying the condition? That's a fair argument for the default UPDATE behavior. It seems we have a consensus that UPDATE operation will use old row. If there is no objections, I will change it in the next version.
We can certainly discuss the possibilities for UPDATE operations. It can choose which row to use: old, new or both (using an additional publication argument or OLD and NEW placeholders to reference old and new rows are feasible ideas). -- Euler Taveira EDB https://www.enterprisedb.com/
