Re: row filtering for logical replication
От | Craig Ringer |
---|---|
Тема | Re: row filtering for logical replication |
Дата | |
Msg-id | CAMsr+YHhMuHn-buDW2FiEw7xZibJjXpTQybZFKfbwLcBNaNAdg@mail.gmail.com обсуждение исходный текст |
Ответ на | row filtering for logical replication (Euler Taveira <euler@timbira.com.br>) |
Ответы |
Re: row filtering for logical replication
|
Список | pgsql-hackers |
On 1 March 2018 at 07:03, Euler Taveira <euler@timbira.com.br> wrote:
Hi,
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().
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.
В списке pgsql-hackers по дате отправления: