From 2a8900e4818dda1349d70df69a72155b590e934e Mon Sep 17 00:00:00 2001 From: "Andrei V. Lepikhov" Date: Mon, 2 Nov 2026 13:58:30 +0100 Subject: [PATCH] Explain that expressions may be evaluated on rows a join removes --- doc/src/sgml/syntax.sgml | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/doc/src/sgml/syntax.sgml b/doc/src/sgml/syntax.sgml index a697218c8b3..ef77b4ae028 100644 --- a/doc/src/sgml/syntax.sgml +++ b/doc/src/sgml/syntax.sgml @@ -2517,6 +2517,30 @@ SELECT somefunc() OR true; in any manner allowed by the laws of Boolean algebra. + + The same applies across the clauses of a query. The logical order in + which a query is described (FROM and joins, then + WHERE, then GROUP BY and + HAVING, then the output list and + ORDER BY) defines the query's result, not the order + in which its expressions are evaluated. + PostgreSQL does not guarantee that an + expression is evaluated only for rows that satisfy the query's join and + WHERE conditions. The planner may evaluate an + expression below a join, and therefore on rows that the join will + eliminate and that never appear in the result. For example, + a WHERE condition that mentions only one table can be + checked while scanning that table; a sort required by + ORDER BY can be performed on one input of a join, + computing the sort key for every row of that input; and aggregation can + be partially performed before a join (see + ), so that aggregate + arguments are evaluated, and aggregate transition functions are called, + for rows that the join will remove. If such an expression can fail for + some input values, the query can raise an error even though none of the + offending rows would have been part of its result. + + When it is essential to force evaluation order, a CASE construct (see ) can be -- 2.56.0