From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
cc: "pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>,
 Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: Volatility - docs vs behaviour?
In-reply-to: <53B20AC4.50901@2ndquadrant.com>
References: <53B12CE7.5090506@2ndquadrant.com>
 <10762.1404143363@sss.pgh.pa.us> <53B20AC4.50901@2ndquadrant.com>
Comments: In-reply-to Craig Ringer <craig@2ndquadrant.com>
 message dated "Tue, 01 Jul 2014 09:11:32 +0800"
Date: Mon, 30 Jun 2014 22:15:47 -0400
Message-ID: <29152.1404180947@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-performance-owner@postgresql.org

Craig Ringer <craig@2ndquadrant.com> writes:
> I was unaware that the planner made any attempt to catch users' errors
> in marking the strictness of functions. I thought it pretty much trusted
> the user not to lie about the mutability of functions invoked
> indirectly. I'm not really sure where in the inlining code to look to
> figure that out.

It's in optimizer/util/clauses.c:

    /*
     * Additional validity checks on the expression.  It mustn't return a set,
     * and it mustn't be more volatile than the surrounding function (this is
     * to avoid breaking hacks that involve pretending a function is immutable
     * when it really ain't).  If the surrounding function is declared strict,
     * then the expression must contain only strict constructs and must use
     * all of the function parameters (this is overkill, but an exact analysis
     * is hard).
     */
    if (expression_returns_set(newexpr))
        goto fail;

    if (funcform->provolatile == PROVOLATILE_IMMUTABLE &&
        contain_mutable_functions(newexpr))
        goto fail;
    else if (funcform->provolatile == PROVOLATILE_STABLE &&
             contain_volatile_functions(newexpr))
        goto fail;

As the comment says, this wasn't really coded with an eye towards
"catching user error".  Rather, there are known use-cases where people
intentionally use SQL wrapper functions to lie about the mutability
of some underlying function; inlining would expose the truth of the
matter and thus defeat such hacks.  Now I'd be the first to agree
that this isn't a terribly high-performance way of doing that, but
the point here was to not change the behavior that existed before
SQL inlining did.

			regards, tom lane


-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance