On Wed, Jul 2, 2014 at 9:47 AM, Stephen Frost <sfr...@snowman.net> wrote: >> But you could do it other ways. For example: >> >> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY; >> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING qual; >> >> If a table is set to NO ROW LEVEL SECURITY then it behaves just like >> it does now: anyone who accesses it sees all the rows, restricted to >> those columns for which they have permission. If the table is set to >> ROW LEVEL SECURITY then the default is to show no rows. The second >> command then allows access to a subset of the rows for a give role >> name. In this case, it is probably logical for access to be combined >> via OR. > > I can see value is having a table-level option to indicate if RLS is > applied for that table or not, but I had been thinking we'd just > automatically manage that. That is to say that once you define an RLS > policy for a table, we go look and see what policy should be applied in > each case. With the user able to control that, what happens if they say > "row security" on the table and there are no policies? All access would > show the table as empty?
I said the same thing in the text you quoted immediately above this reply. > What if policies exist and they decide to > 'turn off' RLS for the table- suddenly everyone can see all the rows? That'd be my vote. Sorta like disabling triggers. > Are we getting to a point where there is sufficient agreement that it'd > be worthwhile to really start implementing this? I think we're converging, but it might be a good idea to summarize a specific proposal before you start implementing. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
