| From: | Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> |
|---|---|
| To: | KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp> |
| Cc: | KaiGai Kohei <kaigai(at)ak(dot)jp(dot)nec(dot)com>, pgsql-hackers(at)postgresql(dot)org, robertmhaas(at)gmail(dot)com, sfrost(at)snowman(dot)net |
| Subject: | Re: [RFC] A tackle to the leaky VIEWs for RLS |
| Date: | 2010-06-01 10:53:29 |
| Message-ID: | 4C04E6A9.7050202@enterprisedb.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 01/06/10 13:04, KaiGai Kohei wrote:
> Oops, I missed it. Indeed, operator function is not limited to C-language
> functions, so regular users can create it.
>
> Apart from the topic, does it seem to you reasonable direction to tackle to
> the leaky VIEWs problem?
Yeah, I guess it is.
The general problem is that it seems like a nightmare to maintain this
throughout the planner. Who knows what optimizations this affects, and
do we need to hide things like row-counts in EXPLAIN output? If we try
to be very strict, we can expect a stream of CVEs and security releases
in the future while we find holes and plug them. On the other hand,
using views to restrict access to underlying tables is a very useful
feature, so I'd hate to just give up. We need to decide what level of
isolation we try to accomplish.
--
Heikki Linnakangas
EnterpriseDB http://www.enterprisedb.com
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Simon Riggs | 2010-06-01 11:04:48 | Re: Keepalive for max_standby_delay |
| Previous Message | Heikki Linnakangas | 2010-06-01 10:36:59 | Re: Keepalive for max_standby_delay |