PostgreSQL教程-sql语法-值表达式-表达式计算规则

PostgreSQL教程-sql语法-值表达式-表达式计算规则

4.2.14. 表达式计算规则

子表达式的计算顺序没有被定义。特别地，一个操作符或函数的输入不必按照从左至右或其他任何固定顺序进行计算。

此外，如果一个表达式的结果可以通过只计算其一部分来决定，那么其他子表达式可能完全不需要被计算。例如，如果我们写：

SELECT true OR somefunc();

那么somefunc()将(可能)完全不被调用。如果我们写成下面这样也是一样：

SELECT somefunc() OR true;

注意这和一些编程语言中布尔操作符从左至右的“短路”不同。

因此，在复杂表达式中使用带有副作用的函数是不明智的。在WHERE和HAVING子句中依赖副作用或计算顺序尤其危险，因为在建立一个执行计划时这些子句会被广泛地重新处理。这些子句中布尔表达式(AND/OR/NOT的组合)可能会以布尔代数定律所允许的任何方式被重组。

当有必要强制计算顺序时，可以使用一个CASE结构(见第 9.17 节)。例如，在一个WHERE子句中使用下面的方法尝试避免除零是不可靠的：

SELECT ... WHERE x > 0 AND y/x > 1.5;

但是这是安全的：

SELECT ... WHERE CASE WHEN x > 0 THEN y/x > 1.5 ELSE false END;

一个以这种风格使用的CASE结构将使得优化尝试失败，因此只有必要时才这样做(在这个特别的例子中，最好通过写y > 1.5*x来回避这个问题)。

不过，CASE不是这类问题的万灵药。上述技术的一个限制是， 它无法阻止常量子表达式的提早计算。如第 37.6 节 中所述，当查询被规划而不是被执行时，被标记成 IMMUTABLE的函数和操作符可以被计算。因此

SELECT CASE WHEN x > 0 THEN x ELSE 1/0 END FROM tab;

很可能会导致一次除零失败，因为规划器尝试简化常量子表达式。即便是 表中的每一行都有x > 0(这样运行时永远不会进入到 ELSE分支)也是这样。

虽然这个特别的例子可能看起来愚蠢，没有明显涉及常量的情况可能会发生 在函数内执行的查询中，因为因为函数参数的值和本地变量可以作为常量 被插入到查询中用于规划目的。例如，在PL/pgSQL函数中，使用一个IF-THEN-ELSE语句来 保护一种有风险的计算比把它嵌在一个CASE表达式中要安全得多。

另一个同类型的限制是，一个CASE无法阻止其所包含的聚合表达式 的计算，因为在考虑SELECT列表或HAVING子句中的 其他表达式之前，会先计算聚合表达式。例如，下面的查询会导致一个除零错误， 虽然看起来好像已经这种情况加以了保护：

SELECT CASE WHEN min(employees) > 0

THEN avg(expenses / employees)

END

FROM departments;

min()和avg()聚合会在所有输入行上并行地计算， 因此如果任何行有employees等于零，在有机会测试 min()的结果之前，就会发生除零错误。取而代之的是，可以使用 一个WHERE或FILTER子句来首先阻止有问题的输入行到达 一个聚合函数。