2010/6/1 Heikki Linnakangas <heikki.linnakan...@enterprisedb.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers