Re: [RFC] A tackle to the leaky VIEWs for RLS
От | Heikki Linnakangas |
---|---|
Тема | Re: [RFC] A tackle to the leaky VIEWs for RLS |
Дата | |
Msg-id | 4C04E6A9.7050202@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: [RFC] A tackle to the leaky VIEWs for RLS (KaiGai Kohei <kaigai@kaigai.gr.jp>) |
Ответы |
Re: [RFC] A tackle to the leaky VIEWs for RLS
|
Список | 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 по дате отправления: