2010/9/1 KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>:
> (2010/09/02 11:57), Robert Haas wrote:
>> 2010/9/1 KaiGai Kohei<kaigai(at)ak(dot)jp(dot)nec(dot)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.
The Enterprise Postgres Company
In response to
pgsql-hackers by date
|Next:||From: Fujii Masao||Date: 2010-09-02 03:46:16|
|Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay,
Kevin! Thanks, reviewers!)|
|Previous:||From: KaiGai Kohei||Date: 2010-09-02 03:25:36|
|Subject: Re: leaky views, yet again|