From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Craig Ringer <craig(at)2ndquadrant(dot)com> |
Cc: | "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com> |
Subject: | Re: Volatility - docs vs behaviour? |
Date: | 2014-07-01 02:15:47 |
Message-ID: | 29152.1404180947@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Pujol Mathieu | 2014-07-01 07:46:50 | Re: GIST optimization to limit calls to operator on sub nodes |
Previous Message | Craig Ringer | 2014-07-01 01:11:32 | Re: Volatility - docs vs behaviour? |