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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2010-06-01 14:58:51 | Re: dividing money by money |
Previous Message | Andy Balholm | 2010-06-01 14:55:59 | Re: dividing money by money |