Re: RLS with check option - surprised design

* Pavel Stehule (pavel(dot)stehule(at)gmail(dot)com) wrote:
> I am playing with RLS. I created simple table
>
> table_data (inserted_by text, v integer);
>
> I created two policies
>
> create policy p1 on data with check (inserted_by = session_user);
> create policy p2 on data with check (v between 10 and 1000);
>
> I was surprised so p2 effectively disables p1;

It doesn't disable it at all- both are applied using OR, as documented
and discussed extensively earlier this year..

I'm not against revisiting that and there has been suggestions about
providing a 'RESTRICTED' policy type which AND's them together, but I
hope it isn't surprising to anyone who has looked at the documentation..
You might also have a policy which applies to all roles and then a more
permissive policy for an 'admin' type of user- look at the "Unix passwd"
example outlined in the documentation.

> next a message:
>
> ERROR: new row violates WITH CHECK OPTION for "data"
> DETAIL: Failing row contains (2014-10-05 12:28:30.79652, petr, 1000).
>
> Doesn't inform about broken policy.

I'm guessing this is referring to the above policies and so my comments
there apply.. One thing to note about this is that there is an active
discussion about removing the 'DETAIL' part of that error message as it
may be an information leak.

Thanks,

Stephen