Re: [RFC] Interface of Row Level Security

2012/5/31 Yeb Havinga <yebhavinga(at)gmail(dot)com>:
> On 2012-05-30 21:26, Kohei KaiGai wrote:
>>
>> If we would have an "ideal optimizer", I'd still like the optimizer to
>> wipe out redundant clauses transparently, rather than RLSBYPASS
>> permissions, because it just controls all-or-nothing stuff.
>> For example, if tuples are categorized to unclassified, classified or
>> secret, and RLS policy is configured as:
>>   ((current_user IN ('alice', 'bob') AND X IN ('unclassified',
>> 'classified')) OR (X IN 'unclassified)),
>> superuser can see all the tuples, and alice and bob can see
>> up to classified tuples.
>> Is it really hard to wipe out redundant condition at planner stage?
>> If current_user is obviously 'kaigai', it seems to me the left-side of
>> this clause can be wiped out at the planner stage.
>
>
> The query's RLS policy would be simpler if the RLS policy function that
> returns the WHERE clause would take the user as argument, so its result does
> not contain user conditionals.
>
> IF (current_user IN ('alice', 'bob')
> THEN
>  RETURN X IN ('unclassified', 'classified'))
> ELSE
>  RETURN X IN ('unclassified')
> END IF;
>
Yes, it is a happy case. But the point I'm concern about is, the conditions
to branch cases are not limited to current user-id.
The RLS policy shall be appended at planner stage, so prepared statement
needs to be invalidated whenever its prerequisites are changed.
For example, someone may assign a function that returns RLS policy
depending on whether the current hour is even-number of odd-number.
It implies that we cannot predicate all the cases to invalidate prepared
statement with RLS policy, because of too much flexibility.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>