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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers