Re: RLS with check option - surprised design

2014-10-05 14:16 GMT+02:00 Stephen Frost <sfrost(at)snowman(dot)net>:

> * 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 didn't watch a discussion about RLS this year.

Please, can you show me some use case, where OR has bigger sense than AND?

Thank you

Pavel

>
> 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
>