Re: [v9.2] Fix Leaky View Problem

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: [v9.2] Fix Leaky View Problem
Дата
Msg-id CA+Tgmobc0i4n+-GCXesai7ft49_beWRYXapTJ0HNOZtP2uhcjw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [v9.2] Fix Leaky View Problem  (Kohei KaiGai <kaigai@kaigai.gr.jp>)
Ответы Re: [v9.2] Fix Leaky View Problem
Список 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 по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: Re: Support UTF-8 files with BOM in COPY FROM
Следующее
От: Peter Eisentraut
Дата:
Сообщение: Re: Support UTF-8 files with BOM in COPY FROM