Re: [v9.4] row level security

2013/9/4 Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Wed, Sep 4, 2013 at 10:45 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> 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 = 'alice(at)example(dot)com';
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 <kaigai(at)kaigai(dot)gr(dot)jp>