Re: [v9.2] Fix Leaky View Problem

2011/9/26 Robert Haas <robertmhaas(at)gmail(dot)com>:
> On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai <kaigai(at)kaigai(dot)gr(dot)jp> wrote:
>>> I'm a bit nervous about storing security_barrier in the RTE.  What
>>> happens to stored rules if the security_barrier option gets change
>>> later?
>>>
>> The rte->security_barrier is evaluated when a query referencing security
>> views get expanded. So, rte->security_barrier is not stored to catalog.
>
> I think it is.  If you create a view that involves an RTE, the node
> tree is going to get stored in pg_rewrite.ev_action.  And it's going
> to include the security_barrier attribute, because you added outfuncs
> support for it...
>
> No?
>
IIUC, nested views are also expanded when user's query gets rewritten.
Thus, rte->security_barrier shall be set based on the latest configuration
of the view.
I injected an elog(NOTICE, ...) to confirm the behavior, when security_barrier
flag was set on rte->security_barrier at ApplyRetrieveRule().

postgres=# CREATE VIEW v1 WITH (security_barrier=true) AS SELECT *
FROM t1 WHERE a % 2 = 0;
CREATE VIEW
postgres=# CREATE VIEW v2 WITH (security_barrier=true) AS SELECT a + a
AS aa, b FROM v1;
CREATE VIEW

postgres=# SELECT * FROM v2;
NOTICE: security barrier set on v1
NOTICE: security barrier set on v2
aa | b
----+-----
4 | bbb
(1 row)

postgres=# ALTER TABLE v1 SET (security_barrier=false);
ALTER TABLE
postgres=# SELECT * FROM v2;
NOTICE: security barrier set on v2
aa | b
----+-----
4 | bbb
(1 row)

postgres=# ALTER TABLE v1 SET (security_barrier=true);
ALTER TABLE
postgres=# SELECT * FROM v2;
NOTICE: security barrier set on v1
NOTICE: security barrier set on v2
aa | b
----+-----
4 | bbb
(1 row)

It seems to me the rte->security_barrier flag is correctly set, even
if underlying view's option was changed later.

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>