2012/6/26 Tom Lane <t...@sss.pgh.pa.us>: > Kohei KaiGai <kai...@kaigai.gr.jp> writes: >> 2012/6/26 Robert Haas <robertmh...@gmail.com>: >>> I think you're missing the point. Everyone who has commented on this >>> issue is in favor of having some check that causes the RLS predicate >>> *not to get added in the first place*. > >> Here is a simple idea to avoid the second problematic scenario; that >> assign 0 as cost of has_superuser_privilege(). > > I am not sure which part of "this isn't safe" isn't getting through to > you. Aside from the scenarios Robert mentioned, consider the > possibility that f_malicious() is marked immutable, so that the planner > is likely to call it (to replace the call with its value) before it will > ever think about whether has_superuser_privilege should be called first. > > Please just do what everybody is asking for, and create a bypass that > does not require fragile, easily-broken-by-future-changes assumptions > about what the planner will do with a WHERE clause. > The problem is the way to implement it. If we would have permission checks on planner stage, it cannot handle a case when user-id would be switched prior to executor stage, thus it needs something remedy to handle the scenario correctly. Instead of a unique plan per query, it might be a solution to generate multiple plans depending on user-id, and choose a proper one in executor stage.
Which type of implementation is what everybody is asking for? 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
