Re: [v9.2] Fix Leaky View Problem - Mailing list pgsql-hackers

From Robert Haas
Subject Re: [v9.2] Fix Leaky View Problem
Date
Msg-id CA+Tgmobc0i4n+-GCXesai7ft49_beWRYXapTJ0HNOZtP2uhcjw@mail.gmail.com
Whole thread Raw
In response to Re: [v9.2] Fix Leaky View Problem  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Responses Re: [v9.2] Fix Leaky View Problem
List pgsql-hackers
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?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Peter Eisentraut
Date:
Subject: Re: Support UTF-8 files with BOM in COPY FROM
Next
From: Peter Eisentraut
Date:
Subject: Re: Support UTF-8 files with BOM in COPY FROM