On Fri, Jan 7, 2022 at 5:16 PM Peter Eisentraut <peter.eisentr...@enterprisedb.com> wrote: > > src/backend/commands/tablecmds.c: > > ATExecReplicaIdentity(): Regarding the question of how to handle > REPLICA_IDENTITY_NOTHING: I see two ways to do this. Right now, the > approach is that the user can set the replica identity freely, and we > decide later based on that what we can replicate (e.g., no updates). >
+1. This is what we are trying to do with the row filter patch. It seems Hou-San has also mentioned the same on this thread [1]. > For this patch, that would mean we don't restrict what columns can be > in the column list, but we check what actions we can replicate based > on the column list. The alternative is that we require the column > list to include the replica identity, as the patch is currently doing, > which would mean that REPLICA_IDENTITY_NOTHING can be allowed since > it's essentially a set of zero columns. > > I find the current behavior a bit weird on reflection. If a user > wants to replicate on some columns and only INSERTs, that should be > allowed regardless of what the replica identity columns are. > Right, I also raised the same point [2] related to INSERTs. [1] - https://www.postgresql.org/message-id/OS0PR01MB5716330FFE3803DF887D073C94789%40OS0PR01MB5716.jpnprd01.prod.outlook.com [2] - https://www.postgresql.org/message-id/CAA4eK1%2BFoJ-J7wUG5s8zCtY0iBuN9LcjQcYhV4BD17xhuHfoug%40mail.gmail.com -- With Regards, Amit Kapila.
