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: (view raw, whole thread or download thread mbox)
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.


			regards, tom lane

In response to


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-2017 The PostgreSQL Global Development Group