From: Tom Lane <tgl@sss.pgh.pa.us>
To: Craig Ringer <craig@2ndquadrant.com>
Cc: pgsql-performance@postgresql.org <pgsql-performance@postgresql.org>
Cc: Pavel Stehule <pavel.stehule@gmail.com>
Subject: Re: Volatility - docs vs behaviour?
Date: Mon, 30 Jun 2014 22:15:47 -0400
Message-ID: <29152.1404180947@sss.pgh.pa.us> (raw)
In-Reply-To: <53B20AC4.50901@2ndquadrant.com>
References: <53B12CE7.5090506@2ndquadrant.com>
<10762.1404143363@sss.pgh.pa.us>
<53B20AC4.50901@2ndquadrant.com>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-performance>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: tgl@sss.pgh.pa.us, craig@2ndquadrant.com, pavel.stehule@gmail.com
Subject: Re: Volatility - docs vs behaviour?
In-Reply-To: <29152.1404180947@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox