Re: Column Filtering in Logical Replication
От | Peter Eisentraut |
---|---|
Тема | Re: Column Filtering in Logical Replication |
Дата | |
Msg-id | a5e04445-85a0-ef43-5a02-996ae59f301d@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: Column Filtering in Logical Replication (Tomas Vondra <tomas.vondra@enterprisedb.com>) |
Ответы |
Re: Column Filtering in Logical Replication
|
Список | pgsql-hackers |
On 07.03.22 16:18, Tomas Vondra wrote: > AFAICS these issues should be resolved by the adoption of the row-filter > approach (i.e. it should fail the same way as for row filter). The first two patches (additional testing for row filtering feature) look okay to me. Attached is a fixup patch for your main feature patch (the third one). It's a bit of code and documentation cleanup, but mainly I removed the term "column filter" from the patch. Half the code was using "column list" or similar and half the code "column filter", which was confusing. Also, there seemed to be a bit of copy-and-pasting from row-filter code going on, with some code comments not quite sensible, so I rewrote some of them. Also some code used "rf" and "cf" symbols which were a bit hard to tell apart. A few more letters can increase readability. Note in publicationcmds.c OpenTableList() the wrong if condition was used. I'm still confused about the intended replica identity handling. This patch still checks whether the column list contains the replica identity at DDL time. And then it also checks at execution time. I thought the latest understanding was that the DDL-time checking would be removed. I think it's basically useless now, since as the test cases show, you can subvert those checks by altering the replica identity later.
Вложения
В списке pgsql-hackers по дате отправления: