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 по дате отправления: