On Thu, Jul 3, 2014 at 1:14 AM, Stephen Frost <sfrost@snowman.net> wrote:
> Alright, apologies for it being a bit later than intended, but here's
> what I've come up with thus far.
>
> -- policies defined at a table scope
> -- allows using the same policy name for different tables
> -- with quals appropriate for each table
> ALTER TABLE t1 ADD POLICY p1 USING p1_quals;
> ALTER TABLE t1 ADD POLICY p2 USING p2_quals;
>
> -- used to drop a policy definition from a table
> ALTER TABLE t1 DROP POLICY p1;
>
> -- cascade required when references exist for the policy
> -- from roles
> ALTER TABLE t1 DROP POLICY p1 CASCADE;
>
> ALTER TABLE t1 ALTER POLICY p1 USING new_quals;
>
> -- Controls if any RLS is applied to this table or not
> -- If enabled, all users must access through some policy
> ALTER TABLE table_name [ NO ] ROW LEVEL SECURITY;
>
> -- Associates roles to policies
> ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING p1;
> ALTER TABLE table_name REVOKE ROW ACCESS FROM role_name USING p1;
If you're going to have predicates be table-level and access grants be
table-level, then what's the value in having policies? You could just
do:
ALTER TABLE table_name GRANT ROW ACCESS TO role_name USING quals;
As I see it, the only value in having policies as separate objects is
that you can then, by granting access to the policy, give a particular
user a bundle of rights rather than having to grant each right
individually. But with this design, you've got to create the policy,
then add the quals to it for each table, and then you still have to
give access individually for every <row, table> combination, so what
value is the policy object itself providing?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
