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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers