Re: row filtering for logical replication

Поиск
Список
Период
Сортировка
От Euler Taveira
Тема Re: row filtering for logical replication
Дата
Msg-id CAHE3wgj+JATk+Z4XkU7=aWPX02uwBxhJaTTNHuCRQ0pFqQjNyQ@mail.gmail.com
обсуждение исходный текст
Ответ на Re: row filtering for logical replication  (Petr Jelinek <petr.jelinek@2ndquadrant.com>)
Ответы Re: row filtering for logical replication  (Stephen Frost <sfrost@snowman.net>)
Список pgsql-hackers
Em sex, 23 de nov de 2018 às 11:40, Petr Jelinek
<petr.jelinek@2ndquadrant.com> escreveu:
> But given that this is happening inside output plugin which does not
> have full executor setup and has catalog-only snapshot I am not sure how
> feasible it is to try to merge these two things. As per my previous
> email it's possible that we'll have to be stricter about what we allow
> in expressions here.
>
This feature should be as simple as possible. I don't want to
introduce a huge overhead just for filtering some data. Data sharding
generally uses simple expressions.

> The other issue with merging this is that the use-case for filtering out
> the data in logical replication is not necessarily about security, but
> often about sending only relevant data. So it makes sense to have filter
> on publication without RLS enabled on table and if we'd force that, we'd
> limit usefulness of this feature.
>
Use the same infrastructure as RLS could be a good idea but use RLS
for row filtering is not. RLS is complex.


--
   Euler Taveira                                   Timbira -
http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Konstantin Knizhnik
Дата:
Сообщение: Index-only scan is slower than Index scan.
Следующее
От: Erik Rijkers
Дата:
Сообщение: prewarm compiler warnings