Skip site navigation (1) Skip section navigation (2)

Re: [RFC] A tackle to the leaky VIEWs for RLS

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <gsstark(at)mit(dot)edu>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, 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 14:57:52
Message-ID: 3282.1275404272@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <gsstark(at)mit(dot)edu> writes:
> Heikki's point is still valid though. Consider if it's not a matter of
> filter ordering but rather that a filter is being pushed down inside a
> join. If the join is from the view then it would be unsafe to filter
> the rows before seeing which rows match the join... unless we can
> prove all the rows survive... It would really suck not to do this
> optimization too if for example you have a filter which filters all
> but a single row and then join against a large table...

Well, more generally, any restriction whatsoever that is placed on
the current planner behavior in the name of security will result in
catastrophic performance degradation for some queries.  I agree with
Robert's nearby comments that we need to be selective about which
views we do this to and which functions we distrust.

CREATE SECURITY VIEW, anyone?

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Bruce MomjianDate: 2010-06-01 14:58:51
Subject: Re: dividing money by money
Previous:From: Andy BalholmDate: 2010-06-01 14:55:59
Subject: Re: dividing money by money

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group