2010/9/1 KaiGai Kohei <kai...@ak.jp.nec.com>: > (2010/09/02 11:57), Robert Haas wrote: >> 2010/9/1 KaiGai Kohei<kai...@ak.jp.nec.com>: >>> Right now, it stands on a strict assumption that considers operators >>> implemented with built-in functions are safe; it does not have no >>> possibility to leak supplied arguments anywhere. >>> >>> Please note that this patch does not case about a case when >>> a function inside a view and a function outside a view are >>> distributed into same level and the later function has lower >>> cost value. >> >> Without making some attempt to address these two points, I don't see >> the point of this patch. >> >> Also, I believe we decided previously do this deoptimization only in >> case the user requests it with CREATE SECURITY VIEW. >> > Perhaps, I remember the previous discussion incorrectly. > > If we have a hint about whether the supplied view is intended to security > purpose, or not, it seems to me it is a reliable method to prevent pulling > up the subqueries come from security views. > Is it too much deoptimization?
Well, that'd prevent something like id = 3 from getting pushed down, which seems a bit harsh. -- 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
