From: | Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> |
---|---|
To: | Alvaro Herrera <alvherre(at)2ndquadrant(dot)com> |
Cc: | Ken Tanzer <ken(dot)tanzer(at)gmail(dot)com>, David G Johnston <david(dot)g(dot)johnston(at)gmail(dot)com>, David Rowley <david(dot)rowley(at)2ndquadrant(dot)com>, PG-General Mailing List <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Will there ever be support for Row Level Security on Materialized Views? |
Date: | 2018-08-28 08:42:51 |
Message-ID: | CAEZATCXYWO-TmGNsgdauLesr-EuR+3G3DincDAQ3hK03B2QFqg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 28 August 2018 at 01:49, Alvaro Herrera <alvherre(at)2ndquadrant(dot)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?
Regards,
Dean
From | Date | Subject | |
---|---|---|---|
Next Message | Andreas Kretschmer | 2018-08-28 08:45:35 | Re: Which background task looks for pg_xlog in 10? |
Previous Message | Haroldo Stenger | 2018-08-28 07:49:09 | Re: How to search particular line/text code in all Postgres all database object's |