Greetings, * Dean Rasheed (dean.a.rasheed@xxxxxxxxx) wrote: > On 28 August 2018 at 01:49, Alvaro Herrera <alvherre@xxxxxxxxxxxxxxx> wrote: > > On 2018-Aug-27, Ken Tanzer wrote: > >> - In the scheme of things, is it a lot of work or not so much? > > > > Probably not much. > > Yeah, it doesn't seem like it would be particularly difficult, but it > would probably still be a reasonable amount of work to go round > finding all the places in code that would need updating. I.e., I think > it would be more mechanical work, than anything fundamentally > challenging. > > On the face of it, it seems like it might be a reasonable thing to > support, but I wonder, is this really just syntactic sugar for > creating a security barrier view on top of the materialized view? > > When RLS was originally implemented, that same question was asked for > tables, but the answer was "no" because RLS on a table gives you > fine-grained (row-level) control over what data in the table can be > modified as well as read, which a SB view doesn't give you. But for a > MV view, that's not a consideration, so what would RLS on a MV > actually give you? I see value in being able to have a consistent set of policies which are applied across tables, views, matviews, etc. Also, with simple updateable views, updates can be done, so there's also that to consider. Ultimately, I do think it'd be good to have RLS support for views, mat views, and foreign tables. Thanks! Stephen
Attachment:
signature.asc
Description: PGP signature
