2012/7/17 Robert Haas <robertmh...@gmail.com>: > On Sun, Jul 15, 2012 at 5:52 AM, Kohei KaiGai <kai...@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 <kai...@kaigai.gr.jp> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
