2014-10-05 14:16 GMT+02:00 Stephen Frost <sfr...@snowman.net>: > * Pavel Stehule (pavel.steh...@gmail.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 >
