Re: [v9.2] Fix Leaky View Problem

2011/11/2 Tom Lane <tgl@sss.pgh.pa.us>:
> Kohei KaiGai <kaigai@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 <kaigai@kaigai.gr.jp>