2010/7/21 KaiGai Kohei <kai...@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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
