Kohei KaiGai wrote:
>> I don't think I like ALTER TABLE as a syntax for row level
>> security. How about using existing GRANT syntax but allowing a
>> WHERE clause? That seems more natural to me, and it would make
>> it easy to apply the same conditions to multiple types of
>> operations when desired, but use different expressions when
>> desired.
>
> It seems to me this syntax gives an impression that row-security
> feature is tightly combined with role-mechanism, even though it
> does not need. For example, we can set row-security policy of
> primary key is even/odd number, independent from working role.
Is there some high-level discussion of the concept of row level
security that operates independently of roles? I'm having a little
trouble getting my head around the idea, there is no README in the
patch, and the Wiki page on RLS hasn't been updated for two and a
half years and seems to be mainly discussing the possibility of
adding non-leaky views (which we now have). If it doesn't control
which roles have access to which rows, what does it do,
conceptually? (A URL to a page explaining this would be fine.)
-Kevin
