From: | Euler Taveira <euler(at)timbira(dot)com(dot)br> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: row filtering for logical replication |
Date: | 2018-03-01 23:15:37 |
Message-ID: | CAHE3wghpw3n0BYr3ewoXA=d+cOaP3NDa-+4jKkitdQpkzqhJdw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
2018-02-28 21:54 GMT-03:00 Craig Ringer <craig(at)2ndquadrant(dot)com>:
> 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.
>
IIRC implementation is similar to RLS expressions. I'll check all of
these rules.
--
Euler Taveira Timbira -
http://www.timbira.com.br/
PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
From | Date | Subject | |
---|---|---|---|
Next Message | David Steele | 2018-03-01 23:16:17 | Re: row filtering for logical replication |
Previous Message | Andres Freund | 2018-03-01 23:07:12 | Re: Challenges preventing us moving to 64 bit transaction id (XID)? |