I rebased my patch set. New functions in pg_proc.h prevented to apply previous revision cleanly. Here is no functional changes.
2011/11/3 Kohei KaiGai <kai...@kaigai.gr.jp>: > 2011/11/2 Tom Lane <t...@sss.pgh.pa.us>: >> Kohei KaiGai <kai...@kaigai.gr.jp> writes: >>> The reason why I redefined the relid of RangeTblEntry is to avoid >>> the problem when security_barrier attribute get changed by concurrent >>> transactions between rewriter and planenr stage. >> >> This is complete nonsense. If the information is being injected into >> the querytree by the rewriter, it's sufficient to assume that it's up to >> date. Were it not so, we'd have problems with CREATE OR REPLACE RULE, >> too. >> > I revised the patches to revert redefinition in relid of RangeTblEntry, and > add a flag of "security_barrier". > I seems to work fine, even if view's property was changed between > rewriter and planner stage. > > postgres=# CREATE VIEW v1 WITH (security_barrier) AS SELECT * FROM t1 > WHERE a % 2 = 0; > CREATE VIEW > postgres=# PREPARE p1 AS SELECT * FROM v1 WHERE f_leak(b); > PREPARE > postgres=# EXECUTE p1; > NOTICE: f_leak => bbb > NOTICE: f_leak => ddd > a | b > ---+----- > 2 | bbb > 4 | ddd > (2 rows) > > postgres=# ALTER VIEW v1 SET (security_barrier=false); > ALTER VIEW > postgres=# EXECUTE p1; > NOTICE: f_leak => aaa > NOTICE: f_leak => bbb > NOTICE: f_leak => ccc > NOTICE: f_leak => ddd > NOTICE: f_leak => eee > a | b > ---+----- > 2 | bbb > 4 | ddd > (2 rows) > > postgres=# ALTER VIEW v1 SET (security_barrier=true); > ALTER VIEW > postgres=# EXECUTE p1; > NOTICE: f_leak => bbb > NOTICE: f_leak => ddd > a | b > ---+----- > 2 | bbb > 4 | ddd > (2 rows) > > Thanks, > -- > KaiGai Kohei <kai...@kaigai.gr.jp> -- 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
