Re: leaky views, yet again

2010/7/21 KaiGai Kohei <kaigai@ak.jp.nec.com>:
> (2010/07/20 2:13), Heikki Linnakangas wrote:
>> On 09/07/10 06:47, KaiGai Kohei wrote:
>>> When leaky and non-leaky functions are chained within a WHERE clause,
>>> it will be ordered by the cost of functions. So, we have possibility
>>> that leaky functions are executed earlier than non-leaky functions.
>>
>> No, that needs to be forbidden as part of the fix. Leaky functions must
>> not be executed before all the quals from the view are evaluated.
>>
>
> IIUC, a view is extracted to a subquery in the rewriter phase, then it
> can be pulled up to join clause at pull_up_subqueries(). In this case,
> WHERE clause may have the quals come from different origins, isn't it?
>
> E.g)
>  SELECT * FROM v1 WHERE f_malicious(v1.a);
>
>  At the rewriter:
>  -> SELECT v1.* FROM (SELECT * FROM t1 WHERE f_policy(t1.b)) v1 WHERE f_malicious(v1.a);
>
>  At the pull_up_subqueries()
>  -> SELECT * FROM t1 WHERE f_policy(t1.b) AND f_malicious(t1.a);
>                            ^^^^^^^^^^^^^^     ^^^^^^^^^^^^^^^^^
>                             cost = 100         cost = 0.0001
>
> Apart from an idea of secure/leaky function mark, isn't it necessary any
> mechanism to enforce f_policy() shall be executed earlier than f_malicious()?

I think you guys are in fact agreeing with each other.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company