On 2021-Jul-14, Tomas Vondra wrote: > On 7/14/21 4:52 PM, Alvaro Herrera wrote:
> > 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. Yeah, I said that too in my older reply :-) > 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. ... if you're saying the user can change the replica identity after we have some publications with filters defined, then I think we should verify during ALTER TABLE and not allow the change if there's a publication that requires it. I mean, during decoding we should be able to simply assume that the tuple is correct for what we need at that point. -- Álvaro Herrera Valdivia, Chile — https://www.EnterpriseDB.com/
