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

From Tom Lane
Subject Re: [RFC] A tackle to the leaky VIEWs for RLS
Date
Msg-id 3282.1275404272@sss.pgh.pa.us
Whole thread Raw
In response to Re: [RFC] A tackle to the leaky VIEWs for RLS  (Greg Stark <gsstark@mit.edu>)
Responses Re: [RFC] A tackle to the leaky VIEWs for RLS  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
Greg Stark <gsstark@mit.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


pgsql-hackers by date:

Previous
From: Andy Balholm
Date:
Subject: Re: dividing money by money
Next
From: Bruce Momjian
Date:
Subject: Re: dividing money by money