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

[ catching up on email post-vacation ]

Qingqing Zhou <zhouqq(dot)postgres(at)gmail(dot)com> writes:
> On Mon, Apr 6, 2015 at 4:22 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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