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/
