Re: Volatility - docs vs behaviour?

Craig Ringer <craig(at)2ndquadrant(dot)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