Date: Thu, 6 Jan 2022 09:29:31 -0300
From: Alvaro Herrera <alvherre@alvh.no-ip.org>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Peter Eisentraut <peter.eisentraut@enterprisedb.com>,
	Rahila Syed <rahilasyed90@gmail.com>,
	PostgreSQL-development <pgsql-hackers@postgresql.org>
Subject: Re: Column Filtering in Logical Replication
Message-ID: <202201061229.2djbvmxaddlp@alvherre.pgsql>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAA4eK1JG9sg8FEx=gKVdtKNA6UpGzqkW0DEftcByP_DoSAHN4Q@mail.gmail.com>
Archived-At: <https://www.postgresql.org/message-id/202201061229.2djbvmxaddlp%40alvherre.pgsql>
Precedence: bulk

On 2022-Jan-06, Amit Kapila wrote:

> Considering this, don't we need to deal with "For All Tables" and "For
> All Tables In Schema .." Publications in this query? The row filter
> patch deal with such cases. The row filter patch handles the NULL case
> via C code which makes the query relatively simpler.

Yes.  I realized after sending that email that the need to handle schema
publications would make a single query very difficult, so I ended up
splitting it again in two queries, which is what you see in the latest
version submitted.

> I am not sure if the same logic can be used here but having a simple
> query here have merit that if we want to use a single query to fetch
> both column and row filters then we should be able to enhance it
> without making it further complicated.

I have looked the row filter code a couple of times to make sure we're
somewhat compatible, but didn't look closely enough to see if we can
make the queries added by both patches into a single one.

> Shouldn't we try to have a behavior similar to the row filter patch
> for this case? The row filter patch behavior is as follows: "If your
> publication contains a partitioned table, the publication parameter
> publish_via_partition_root determines if it uses the partition row
> filter (if the parameter is false, the default) or the root
> partitioned table row filter. During initial tablesync, it doesn't do
> any special handling for partitions.

I'll have a look.

Thanks for looking!

-- 
Álvaro Herrera              Valdivia, Chile  —  https://www.EnterpriseDB.com/