2011/9/26 Robert Haas <robertmh...@gmail.com>: > On Sun, Sep 25, 2011 at 3:25 PM, Kohei KaiGai <kai...@kaigai.gr.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 <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
