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:
@@ -11179,11 +11179,13 @@ SELECT ... WHERE CASE WHEN x <> 0 THEN y/x > 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>
|
||||
|
Reference in New Issue
Block a user