1
0
mirror of https://github.com/postgres/postgres.git synced 2025-08-30 06:01:21 +03:00

Improve documentation about CASE and constant subexpressions.

The possibility that constant subexpressions of a CASE might be evaluated
at planning time was touched on in 9.17.1 (CASE expressions), but it really
ought to be explained in 4.2.14 (Expression Evaluation Rules) which is the
primary discussion of such topics.  Add text and an example there, and
revise the <note> under CASE to link there.

Back-patch to all supported branches, since it's acted like this for a
long time (though 9.2+ is probably worse because of its more aggressive
use of constant-folding via replanning of nominally-prepared statements).
Pre-9.4, also back-patch text added in commit 0ce627d4 about CASE versus
aggregate functions.

Tom Lane and David Johnston, per discussion of bug #12273.
This commit is contained in:
Tom Lane
2014-12-18 16:38:52 -05:00
parent cd6e66572b
commit 5b51683589
2 changed files with 36 additions and 7 deletions

View File

@@ -11179,11 +11179,13 @@ SELECT ... WHERE CASE WHEN x &lt;&gt; 0 THEN y/x &gt; 1.5 ELSE false END;
<note>
<para>
As described in <xref linkend="xfunc-volatility">, functions and
operators marked <literal>IMMUTABLE</literal> can be evaluated when
the query is planned rather than when it is executed. This means
that constant parts of a subexpression that is not evaluated during
query execution might still be evaluated during query planning.
As described in <xref linkend="syntax-express-eval">, there are various
situations in which subexpressions of an expression are evaluated at
different times, so that the principle that <quote><token>CASE</token>
evaluates only necessary subexpressions</quote> is not ironclad. For
example a constant <literal>1/0</> subexpression will usually result in
a division-by-zero failure at planning time, even if it's within
a <token>CASE</token> arm that would never be entered at run time.
</para>
</note>
</sect2>