On 7/14/21 4:52 PM, Alvaro Herrera wrote:
On 2021-Jul-14, Tomas Vondra wrote:
The way I'm thinking about this is that for INSERT and DELETE it's clear
which row version should be used (because there's just one). And for UPDATE
we could see that as DELETE + INSERT, and apply the same rule to each
action.
On the other hand, I can imagine cases where it'd be useful to send the
UPDATE when the old row matches the condition and new row does not.
In any case, it seems to me that the condition expression should be
scanned to see which columns are used in Vars (pull_varattnos?), and
verify if those columns are in the REPLICA IDENTITY; and if they are
not, raise an error. Most of the time the REPLICA IDENTITY is going to
be the primary key; but if the user wants to use other columns in the
expression, we can HINT that they can set REPLICA IDENTITY FULL.
Yeah, but AFAIK that's needed only when replicating DELETEs, so perhaps
we could ignore this for subscriptions without DELETE.
The other question is when to check/enforce this. I guess we'll have to
do that during decoding, not just when the publication is being created,
because the user can do ALTER TABLE later.
regards
--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
