2012/5/31 Yeb Havinga <yebhavi...@gmail.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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers