Re: [RFC] A tackle to the leaky VIEWs for RLS

2010/6/1 Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>:
> On 01/06/10 11:39, KaiGai Kohei wrote:
>> Any operators eventually invokes a function
>> being correctly installed, but an assumption is that we can trust operators,
>> index access method, type input/output methods, conversions and so on, because
>> these features have to be installed by DBA (or initdb).
>
> Operators can be created by regular users.

So I think we don't actually have to worry about operators and
functions which allow us to use an index scan. If they're used in an
index definition then the definer of those functions can see the
entire table anyways.

The only place where this matters, at least to a first degree, is on
the filter operations applied to a scan. If the view isn't owned by
the current user then all the filters of the view have to be enforced
first then the query filters.

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...

--
greg