2011/9/26 Robert Haas <robertmhaas@gmail.com>:
> On Mon, Sep 26, 2011 at 5:58 AM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
>>> 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().
>
> Hmm, OK. I am still not convinced that this is the right approach.
> Normally, we don't cache anything in the RangeTblEntry that might
> change between plan time and execution time. Those things are
> normally stored in the RelOptInfo - why not do the same here?
>
The point is that a sub-query come from a particular view does not
keep the information what view originally stored the sub-query when
it was passed to the executor stage.
PostgreSQL handles a view as just a sub-query after the rewriter stage.
One possible idea not to store the flag in RangeTblEntry is to utilize
rte->relid to show the relation-id of the source view, when rtekind is
RTE_SUBQUERY; that enables to pull the security_barrier flag in
executor stage.
However, the interface to reference reloptions are designed to pull
this information with Relation pointer, rather than lsyscache, so
I implemented this revision with a new rte->security_barrier member.
Thanks,
--
KaiGai Kohei <kaigai@kaigai.gr.jp>