From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com> |
Cc: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>, pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: leaky views, yet again |
Date: | 2010-09-02 02:57:08 |
Message-ID: | AANLkTin7Nr_e6yObKjUcu+SCpxHXsAAUKip0dkN6Q=Hb@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-09-02 02:58:13 | Re: multibyte charater set in levenshtein function |
Previous Message | Tom Lane | 2010-09-02 00:57:43 | Re: compiling with RELCACHE_FORCE_RELEASE doesn't pass regression |