Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node
Дата
Msg-id 29122.1429896649@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node  (Qingqing Zhou <zhouqq.postgres@gmail.com>)
Ответы Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node  (Andres Freund <andres@anarazel.de>)
Список pgsql-committers
[ catching up on email post-vacation ]

Qingqing Zhou <zhouqq.postgres@gmail.com> writes:
> On Mon, Apr 6, 2015 at 4:22 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> Because it's expensive (a syscache lookup per function or operator).
>> And that test alone would be insufficient anyway: you'd also have to
>> check that there was an appropriate Var in the expression, cf the
>> comment for contain_nonstrict_functions.

> Looks like not only contain_nonstrict_functions() is expensive, but
> other contain_xxx family members.

> In FuncExpr structure, for example, we already cached values like
> retset, resulttype, but why not volatile and isstrict? In this way, we
> avoid cache lookup every time. So as OpExpr etc.

The reason we don't store those in the expression tree is that changing
those properties (eg with CREATE OR REPLACE FUNCTION) would break stored
views referencing the function.  It's okay to store resulttype and retset
because we disallow changing the output type (including set-ness) of a
function; but we don't want to disallow changing strictness for instance.

            regards, tom lane


В списке pgsql-committers по дате отправления:

Предыдущее
От: Peter Eisentraut
Дата:
Сообщение: pgsql: doc: Move ALTER TABLE IF EXISTS description to better place
Следующее
От: Heikki Linnakangas
Дата:
Сообщение: pgsql: Add comments explaining how unique and exclusion constraints are