Greetings, * Euler Taveira (eu...@timbira.com.br) wrote: > 2018-02-28 21:54 GMT-03:00 Craig Ringer <cr...@2ndquadrant.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.
Given the similarity to RLS and the nearby discussion about allowing non-superusers to create subscriptions, and probably publications later, I wonder if we shouldn't be somehow associating this with RLS policies instead of having the publication filtering be entirely independent.. Thanks! Stephen
signature.asc
Description: PGP signature
