Greetings,
* Dean Rasheed (dean.a.rasheed@gmail.com) wrote:
> On 28 August 2018 at 01:49, Alvaro Herrera <alvherre@2ndquadrant.com> 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