On Fri, Jan 9, 2015 at 7:54 AM, Dean Rasheed <dean.a.rasheed@gmail.com> wrote:
> A while ago [1] I proposed an enhancement to the way qual pushdown
> safety is decided in RLS / security barrier views. Currently we just
> test for the presence of leaky functions in the qual, but it is
> possible to do better than that, by further testing if the leaky
> function is actually being passed information that we don't want to be
> leaked.
>
> Attached is a patch that does that, allowing restriction clause quals
> to be pushed down into subquery RTEs if they contain leaky functions,
> provided that the arglists of those leaky functions contain no Vars
> (such Vars would necessarily refer to output columns of the subquery,
> which is the data that must not be leaked).
>
> An example of the sort of query this will help optimise is:
>
> SELECT * FROM table_with_rls WHERE created > now() - '1 hour'::interval;
>
> where currently this qual cannot be pushed down because neither now()
> nor timestamptz_mi_interval() are leakproof, but since they are not
> being passed any data from the table, they can't actually leak
> anything, so the qual can be safely pushed down, allowing indexes to
> be used if available.
One thing they could still leak is the number of times they got
called, and thus possibly the number of unseen rows. Now if the
expressions get constant-folded away that won't be an issue, but a
clever user can probably avoid that.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
