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

From Tom Lane
Subject Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node
Date
Msg-id 29122.1429896649@sss.pgh.pa.us
Whole thread Raw
In response to Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node  (Qingqing Zhou <zhouqq.postgres@gmail.com>)
Responses Re: pgsql: Fix incorrect matching of subexpressions in outer-join plan node
List 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 by date:

Previous
From: Peter Eisentraut
Date:
Subject: pgsql: doc: Move ALTER TABLE IF EXISTS description to better place
Next
From: Heikki Linnakangas
Date:
Subject: pgsql: Add comments explaining how unique and exclusion constraints are