Re: [v9.3] Row-Level Security
От | Tom Lane |
---|---|
Тема | Re: [v9.3] Row-Level Security |
Дата | |
Msg-id | 13017.1340744395@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [v9.3] Row-Level Security (Kohei KaiGai <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [v9.3] Row-Level Security
|
Список | pgsql-hackers |
Kohei KaiGai <kaigai@kaigai.gr.jp> writes: > 2012/6/26 Robert Haas <robertmhaas@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. regards, tom lane
В списке pgsql-hackers по дате отправления: