Re: [RFC] A tackle to the leaky VIEWs for RLS
От | Tom Lane |
---|---|
Тема | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Дата | |
Msg-id | 3282.1275404272@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [RFC] A tackle to the leaky VIEWs for RLS (Greg Stark <gsstark@mit.edu>) |
Ответы |
Re: [RFC] A tackle to the leaky VIEWs for RLS
|
Список | pgsql-hackers |
Greg Stark <gsstark@mit.edu> writes: > Heikki's point is still valid though. Consider if it's not a matter of > filter ordering but rather that a filter is being pushed down inside a > join. If the join is from the view then it would be unsafe to filter > the rows before seeing which rows match the join... unless we can > prove all the rows survive... It would really suck not to do this > optimization too if for example you have a filter which filters all > but a single row and then join against a large table... Well, more generally, any restriction whatsoever that is placed on the current planner behavior in the name of security will result in catastrophic performance degradation for some queries. I agree with Robert's nearby comments that we need to be selective about which views we do this to and which functions we distrust. CREATE SECURITY VIEW, anyone? regards, tom lane
В списке pgsql-hackers по дате отправления: