RE: row filtering for logical replication - Mailing list pgsql-hackers

From tanghy.fnst@fujitsu.com
Subject RE: row filtering for logical replication
Date
Msg-id OS0PR01MB6113F2E024961A9C7F36BEADFB679@OS0PR01MB6113.jpnprd01.prod.outlook.com
Whole thread Raw
In response to Re: row filtering for logical replication  (Peter Smith <smithpb2250@gmail.com>)
Responses Re: row filtering for logical replication
List pgsql-hackers
On Thursday, November 25, 2021 11:22 AM Peter Smith <smithpb2250@gmail.com> wrote:
> 
> Thanks for all the review comments so far! We are endeavouring to keep
> pace with them.
> 
> All feedback is being tracked and we will fix and/or reply to everything ASAP.
> 
> Meanwhile, PSA the latest set of v42* patches.
> 
> This version was mostly a patch restructuring exercise but it also
> addresses some minor review comments in passing.
> 

Thanks for your patch.
I have two comments on the document in 0001 patch.

1.
+   New row is used and it contains all columns. A <literal>NULL</literal> value
+   causes the expression to evaluate to false; avoid using columns without

I don't quite understand this sentence 'A NULL value causes the expression to evaluate to false'. 
The expression contains NULL value can also return true. Could you be more specific?

For example:

postgres=# select null or true;
 ?column?
----------
 t
(1 row)


2.
+   at all then all other filters become redundant. If the subscriber is a
+   <productname>PostgreSQL</productname> version before 15 then any row filtering
+   is ignored.

If the subscriber is a PostgreSQL version before 15, it seems row filtering will
be ignored only when copying initial data, the later changes will not be ignored in row
filtering. Should we make it clear in document?

Regards,
Tang

pgsql-hackers by date:

Previous
From: Masahiko Sawada
Date:
Subject: Re: Rename dead_tuples to dead_items in vacuumlazy.c
Next
From: Greg Nancarrow
Date:
Subject: Re: Optionally automatically disable logical replication subscriptions on error