2013/9/4 Tom Lane <[email protected]>: > Robert Haas <[email protected]> writes: >> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane <[email protected]> wrote: >>> Well, the security-barrier view stuff did not present itself as a 100% >>> solution. But perhaps more to the point, it was conceptually simple to >>> implement, ie don't flatten views if they have this bit set, and don't >>> push down quals into such sub-selects unless they're marked leakproof. > >> Right. IMHO, this new feature should be similarly simple: when an >> unprivileged user references a table, treat that as a reference to a >> leakproof view over the table, with the RLS qual injected into the >> view. > > And for insert/update/delete, we do what exactly? > This patch does not care about insert, because it shall be done around the place where we usually put before-row-insert; that is not related to planner.
Regarding to update/delete, this patch also enhanced to allow update or delete mechanism allows to take a sub-query on top of the table scan plan. So, its explain output shows as follows: postgres=> EXPLAIN (costs off) UPDATE customer SET email = '[email protected]'; QUERY PLAN -------------------------------------------------- Update on customer -> Subquery Scan on customer -> Seq Scan on customer customer_1 Filter: ("current_user"() = uname) You can see this update has Subquery plan instead of regular relation scan. Thanks, -- KaiGai Kohei <[email protected]> -- Sent via pgsql-hackers mailing list ([email protected]) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
