The attached patches add support for filtering rows in the publisher. The output plugin will do the work if a filter was defined in CREATE PUBLICATION command. An optional WHERE clause can be added after the table name in the CREATE PUBLICATION such as:
CREATE PUBLICATION foo FOR TABLE departments WHERE (id > 2000 AND id <= 3000);
Row that doesn't match the WHERE clause will not be sent to the subscribers.
Patches 0001 and 0002 are only refactors and can be applied independently. 0003 doesn't include row filtering on initial synchronization.
Good idea. I haven't read this yet, but one thing to make sure you've handled is limiting the clause to referencing only the current tuple and the catalogs. user-catalog tables are OK, too, anything that is RelationIsAccessibleInLogicalDecoding().
This means only immutable functions may be invoked, since a stable or volatile function might attempt to access a table. And views must be prohibited or recursively checked. (We have tree walkers that would help with this).
It might be worth looking at the current logic for CHECK expressions, since the requirements are similar. In my opinion you could safely not bother with allowing access to user catalog tables in the filter expressions and limit them strictly to immutable functions and the tuple its self.