2012/6/4 Tom Lane <t...@sss.pgh.pa.us>: > Kohei KaiGai <kai...@kaigai.gr.jp> writes: >> Here is two problems around RLSBYPASS. The first is we have >> no idea to handle invalidation of prepared-statement when current >> user is switched, right now. > > How is that specifically the fault of RLSBYPASS? *Any* of the schemes > you're proposing for inlined RLS checks will have problems with userID > switching. > Really? I don't find out a scenario that cause a problem with user-id switching in case when RLS policy is *unconditionally* appended then evaluated on executor stage. I'd like to see the scenario.
> My guess is we'd have to treat the effective userID as part of the > plancache lookup key to make it safe to inline anything related to RLS. > It might be a solution, if we append individual RLS policy at the planner stage, depending on user-id. 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
