Re: row filtering for logical replication

From: Euler Taveira <euler(at)timbira(dot)com(dot)br>
To: Petr Jelinek <petr(dot)jelinek(at)2ndquadrant(dot)com>
Cc: sfrost(at)snowman(dot)net, Craig Ringer <craig(at)2ndquadrant(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: row filtering for logical replication
Date: 2018-11-23 15:17:12
Message-ID: CAHE3wgj+JATk+Z4XkU7=aWPX02uwBxhJaTTNHuCRQ0pFqQjNyQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Em sex, 23 de nov de 2018 às 11:40, Petr Jelinek
<petr(dot)jelinek(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2018-11-23 15:20:25 Re: pgsql: Add WL_EXIT_ON_PM_DEATH pseudo-event.
Previous Message Konstantin Knizhnik 2018-11-23 14:51:37 Index-only scan is slower than Index scan.