2012/7/17 Robert Haas <robertmhaas@gmail.com>:
> On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>> The attached patch is a revised version of row-level security feature.
>>
>> I added a feature to invalidate plan cache if user-id was switched
>> between planner and optimizer. It enabled to generate more optimized
>> plan than the previous approach; that adds hardwired "OR superuser()".
>>
>> Example)
>> postgres=# PREPARE p1(int) AS SELECT * FROM t1 WHERE x > $1 AND f_leak(y);
>> PREPARE
>> postgres=# EXPLAIN (costs off) EXECUTE p1(2);
>> QUERY PLAN
>> -----------------------------------
>> Seq Scan on t1
>> Filter: (f_leak(y) AND (x > 2))
>> (2 rows)
>>
>> postgres=# SET SESSION AUTHORIZATION alice;
>> SET
>> postgres=> EXPLAIN (costs off) EXECUTE p1(2);
>> QUERY PLAN
>> ---------------------------------------------
>> Subquery Scan on t1
>> Filter: f_leak(t1.y)
>> -> Seq Scan on t1
>> Filter: ((x > 2) AND ((x % 2) = 0))
>> (4 rows)
>>
>> On the other hand, I removed support for UPDATE / DELETE commands
>> in this revision, because I'm still uncertain on the implementation that I
>> adopted in the previous patch. I believe it helps to keep patch size being
>> minimum reasonable.
>> Due to same reason, RLS is not supported on COPY TO command.
>>
>> According to the Robert's comment, I revised the place to inject
>> applyRowLevelSecurity(). The reason why it needed to patch on
>> adjust_appendrel_attrs_mutator() was, we handled expansion from
>> regular relation to sub-query after expand_inherited_tables().
>> In this revision, it was moved to the head of sub-query planner.
>>
>> Even though I added a syscache entry for pg_rowlevelsec catalog,
>> it was revised to read the catalog on construction of relcache, like
>> trigger descriptor, because it enables to reduce cost to parse an
>> expression tree in text format and memory consumption of hash
>> slot.
>>
>> This revision adds support on pg_dump, and also adds support
>> to include SubLinks in the row-level security policy.
>
> This revision is too late for this CommitFest; I've moved it to the
> next CommitFest and will look at it then, or hopefully sooner.
>
It seems to me fair enough. I may be able to add UPDATE /
DELETE support until next commit-fest.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>