Tom, all, * Tom Lane (t...@sss.pgh.pa.us) wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Wed, Nov 2, 2016 at 10:46 PM, Sounak Chakraborty <soun...@gmail.com> > > wrote: > >> But my doubt is why this feature is not enabled in case of Foreign Table. > >> (ALTER FOREIGN TABLE doesn't have a option of enabling Row Level Security). > >> Is this is not implemented due to some limitations in the current design? > >> Because from a quick view it looks like the security subquery can also be > >> easily attached to the main query and passed for processing in foreign > >> database. > > > Yeah, I don't see why that couldn't be made to work. > > Once the patch at <30304.1478211...@sss.pgh.pa.us> gets in, the major > issue will be that FDWs will have to be careful not to select quals for > optimization (ie pushing down to a remote server) unless they satisfy > restriction_is_securely_promotable(). In most cases that should be > about a one-line change in the FDW, but I'm not sure that it'd be a good > idea to just blindly assume that FDWs are doing that. We could perhaps > add some sort of "supports RLS" flag to the FDW API, which would not > get set unless the FDW author takes positive action to do so.
That sounds like an entirely reasonable approach to me. Other than that, I agree that FDWs shouldn't be too difficult to add RLS support for as it seems pretty clear what the semantics there should be. Thanks! Stephen
signature.asc
Description: Digital signature
