Re: [RFC] A tackle to the leaky VIEWs for RLS - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: [RFC] A tackle to the leaky VIEWs for RLS
Date
Msg-id 4C04E6A9.7050202@enterprisedb.com
Whole thread Raw
In response to Re: [RFC] A tackle to the leaky VIEWs for RLS  (KaiGai Kohei <kaigai@kaigai.gr.jp>)
Responses Re: [RFC] A tackle to the leaky VIEWs for RLS  (Robert Haas <robertmhaas@gmail.com>)
List 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


pgsql-hackers by date:

Previous
From: KaiGai Kohei
Date:
Subject: Re: [RFC] A tackle to the leaky VIEWs for RLS
Next
From: Simon Riggs
Date:
Subject: Re: Keepalive for max_standby_delay