PostgreSQL 9.4.4 中文手册
上一页 | 上一级 | 章 7. 查询 | 下一页

# 7.2. 表表达式

表表达式计算一个表，它包含一个`FROM`子句， 该子句可以根据需要选用`WHERE`, `GROUP BY`,`HAVING` 子句。大部分表表达式只是指向磁盘上的一个所谓的基本表， 但是我们可以用更复杂的表达式以各种方法修改或组合基本表。

表表达式里的`WHERE`, `GROUP BY`, `HAVING` 子句声明一系列对源自`FROM`子句的表的转换操作。 所有这些转换最后生成一个虚拟表，传递给选择列表计算输出行。

## 7.2.1. `FROM` 子句

FROM 子句 从一个逗号分隔的表引用列表中生成一个虚拟表。

    FROM table_reference [, table_reference [, ...]]

表引用可以是一个表名字(可能有模式修饰)或者是一个生成的表， 比如子查询、`JOIN`构造、或这些东西的复杂组合。 如果在`FROM`子句中列出了多于一个表引用， 那么它们交叉连接(也就是形成了它们的行的笛卡尔积，见下文)。 `FROM`列表的结果是一个中间的虚拟表， 该表可以进行`WHERE`, `GROUP BY`, `HAVING`子句的转换处理，并最后生成表表达式的结果。

如果一个表引用是一个简单的父表的名字，那么将包括其所有后代子表的行， 除非你在该表名字前面加`ONLY`关键字(这样任何子表都会被忽略)。

除了在表名字前面加`ONLY`，你可以在表名字后面写`*` 明确指定包括后代表。写`*`不是必须的，因为这个行为是默认的 （除非你已经改变了sql_inheritance配置选项里面的设置）。 然而写`*`可能对于强调搜索额外的表是有用的。

### 7.2.1.1. 连接表

一个连接表是根据特定的连接规则从两个其它表(真实表或生成表)中派生的表。 我们支持内连接、外连接、交叉连接。连接表的一般语法是

    T1 join_type T2 [ join_condition ]

所有类型的连接都可以串连或嵌套在一起： `T1`和`T2` 之一或全部是可以连接的表。 你可以在`JOIN`子句周围使用圆括弧来控制连接顺序，如果没有圆括弧， 那么`JOIN`子句从左向右嵌套。

连接类型

交叉连接

      T1 CROSS JOIN T2

  对每个来自`T1`和`T2` 的行进行组合（也就是，一个笛卡尔积），连接成的表将包含这样的行： 所有`T1`里面的字段后面跟着所有`T2` 里面的字段。如果两表分别有 N 和 M 行，连接成的表将有 N*M 行。

  `FROM `T1` CROSS JOIN `T2`` 等效于`FROM `T1` INNER JOIN `T2` ON TRUE`(见下文)。 它还等效于`FROM `T1`,`T2``。

  > 注意: 当多于两个表时，不再正确的支持后面的等效，因为`JOIN`的绑定比逗号更紧。 例如`FROM `T1` CROSS JOIN `T2` INNER JOIN `T3` ON `condition`` 和`FROM `T1`, `T2` INNER JOIN `T3` ON `condition`` 不同，因为`condition`在第一种情况下可以引用 `T1`而在第二种情况中则不能。

条件连接

      T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 ON boolean_expression
      T1 { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2 USING ( join column list )
      T1 NATURAL { [INNER] | { LEFT | RIGHT | FULL } [OUTER] } JOIN T2

  `INNER`和`OUTER`对所有连接类型都是可选的。 `INNER`为缺省。`LEFT`, `RIGHT`, 和`FULL`隐含外连接。

  连接条件在`ON`或`USING`子句里声明， 或者用关键字`NATURAL`隐含地声明。 连接条件判断来自两个源表中的那些行是"匹配"的，这些我们将在下面详细解释。

  条件连接可能的类型是：

  `INNER JOIN`

    内连接。对于 T1 中的每一行 R1 ，如果能在 T2 中找到一个或多个满足连接条件的行， 那么这些满足条件的每一行都在连接表中生成一行。

  `LEFT OUTER JOIN`

    左外连接。首先执行一次内连接。然后为每一个 T1 中无法在 T2 中找到匹配的行生成一行， 该行中对应 T2 的列用 NULL 补齐。因此，生成的连接表里总是包含来自 T1 里的每一行至少一个副本。

  `RIGHT OUTER JOIN`

    右外连接。首先执行一次内连接。然后为每一个 T2 中无法在 T1 中找到匹配的行生成一行， 该行中对应 T1 的列用 NULL 补齐。因此，生成的连接表里总是包含来自 T2 里的每一行至少一个副本。

  `FULL OUTER JOIN`

    全连接。首先执行一次内连接。然后为每一个 T1 与 T2 中找不到匹配的行生成一行， 该行中无法匹配的列用 NULL 补齐。因此，生成的连接表里无条件地包含 T1 和 T2 里的每一行至少一个副本。

  `ON`子句是最常见的连接条件的类型：它接收一个和`WHERE` 子句相同的布尔表达式。如果两个分别来自`T1`和`T2` 的行在`ON`表达式上运算的结果为真，那么它们就算是匹配的行。

  `USING`子句是一种速记法，允许你在join两边都使用相同的连接字段名时获取便利。 它接受一个逗号分隔的共享字段名的列表，并生成一个包括每个字段相等比较的连接条件。 例如，用`USING (a, b)`连接`T1`和`T2`， 产生连接条件`ON `T1`.a = `T2`.a AND `T1`.b = `T2`.b`。

  另外，`JOIN USING`的输出抑制多余的字段： 两个匹配的字段不需要都打印出来，因为它们肯定拥有相等的值。 `JOIN ON`产生所有来自`T1`的字段， 后面跟着所有来自`T2`的字段，而`JOIN USING` 产生列出的每个字段对（以列出的顺序），跟着`T1` 中剩余的字段，然后跟着`T2`中剩余的字段。

  最后，`NATURAL`是`USING`的缩写形式： 它自动形成一个由两个表中同名的字段组成的`USING`列表(同名字段只出现一次)。 如果没有相同的字段名，`NATURAL`的行为会像`CROSS JOIN`。

  > 注意: `USING`在连接关系的字段修改中是合理安全的， 因为只组合了列出的字段。认为`NATURAL`更危险一些， 因为两个关系的任何模式改变会导致出现新的匹配字段名， 这将导致连接也组合该新字段。

为了解释这些问题，假设我们有一个表`t1`:

     num | name
    -----+------
       1 | a
       2 | b
       3 | c

和`t2`:

     num | value
    -----+-------
       1 | xxx
       3 | yyy
       5 | zzz

然后我们用不同的连接方式可以获得各种结果：

    => SELECT * FROM t1 CROSS JOIN t2;
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       1 | a    |   3 | yyy
       1 | a    |   5 | zzz
       2 | b    |   1 | xxx
       2 | b    |   3 | yyy
       2 | b    |   5 | zzz
       3 | c    |   1 | xxx
       3 | c    |   3 | yyy
       3 | c    |   5 | zzz
    (9 rows)

    => SELECT * FROM t1 INNER JOIN t2 ON t1.num = t2.num;
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       3 | c    |   3 | yyy
    (2 rows)

    => SELECT * FROM t1 INNER JOIN t2 USING (num);
     num | name | value
    -----+------+-------
       1 | a    | xxx
       3 | c    | yyy
    (2 rows)

    => SELECT * FROM t1 NATURAL INNER JOIN t2;
     num | name | value
    -----+------+-------
       1 | a    | xxx
       3 | c    | yyy
    (2 rows)

    => SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num;
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       2 | b    |     |
       3 | c    |   3 | yyy
    (3 rows)

    => SELECT * FROM t1 LEFT JOIN t2 USING (num);
     num | name | value
    -----+------+-------
       1 | a    | xxx
       2 | b    |
       3 | c    | yyy
    (3 rows)

    => SELECT * FROM t1 RIGHT JOIN t2 ON t1.num = t2.num;
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       3 | c    |   3 | yyy
         |      |   5 | zzz
    (3 rows)

    => SELECT * FROM t1 FULL JOIN t2 ON t1.num = t2.num;
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       2 | b    |     |
       3 | c    |   3 | yyy
         |      |   5 | zzz
    (4 rows)

用`ON`声明的连接条件也可以包含与连接不直接相关的条件。 这种功能可能对某些查询很有用，但是需要我们仔细想清楚。比如：

    => SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num AND t2.value = 'xxx';
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
       2 | b    |     |
       3 | c    |     |
    (3 rows)

请注意，将限制放在在`WHERE`子句中将会产生不同的结果：

    => SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num WHERE t2.value = 'xxx';
     num | name | num | value
    -----+------+-----+-------
       1 | a    |   1 | xxx
    (1 row)

这是因为限制放在`ON`子句中时是先于连接处理的， 而限制放在`WHERE`子句中时是后于连接处理的。 这对内连接来说没什么问题，但是对外连接来说问题就大了。

### 7.2.1.2. 表和列别名

你可以给表或复杂的表引用起一个临时的表别名，以便被其余的查询引用。

要创建一个表别名，可以这样：

    FROM table_reference AS alias

或：

    FROM table_reference alias

`AS`关键字没啥特别的含义。`alias`可以是任意标识符。

表别名的典型应用是给长表名赋予比较短的标识，好让连接子句更易读一些。比如：

    SELECT * FROM some_very_long_table_name s JOIN another_fairly_long_name a ON s.id = a.num;

取了别名之后就不允许再用最初的名字了。因此，这是不合法的：

    SELECT * FROM my_table AS m WHERE my_table.a > 5;    -- wrong

表别名主要是为了方便标记，但对于自连接却是必须的。比如：

    SELECT * FROM people AS mother JOIN people AS child ON mother.id = child.mother_id;

另外，要引用子查询的结果也必须使用别名(参见第 7.2.1.3 节)。

圆括弧用于解决歧义。下面的第一个语句把别名`b`赋予第二个`my_table`表； 而第二个语句则把别名`b`赋予了连接的结果。

    SELECT * FROM my_table AS a CROSS JOIN my_table AS b ...
    SELECT * FROM (my_table AS a CROSS JOIN my_table) AS b ...

另外一种形式的表别名除了给表赋予别名外，还给该表的字段也赋予了别名：

    FROM table_reference [AS] alias ( column1 [, column2 [, ...]] )

如果声明的字段别名比表里实际的字段少，那么后面的字段就没有别名。 这个语法对于自连接或子查询特别有用。

如果用这些形式中的任何一种给一个`JOIN`子句的输出结果附加了一个别名， 那么该别名就在`JOIN`里隐藏了其原始的名字。比如：

    SELECT a.* FROM my_table AS a JOIN your_table AS b ON ...

是合法 SQL ，但是：

    SELECT a.* FROM (my_table AS a JOIN your_table AS b ON ...) AS c

是不合法的：别名`a`在别名`c`的外面是看不到的。

### 7.2.1.3. 子查询

子查询的结果(派生表)必须包围在圆括弧里并且必须赋予一个别名(参阅 第 7.2.1.2 节)。比如：

    FROM (SELECT * FROM table1) AS alias_name

这个例子等效于`FROM table1 AS alias_name`。 更有趣的例子是在子查询里面有分组或聚合的时候， 这个时候子查询不能归纳成一个简单的连接。

子查询也可以是一个`VALUES`列表：

    FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))
         AS names(first, last)

这种情况同样也必须要取一个别名。还可以为`VALUES`列表中的字段取别名， 并且被认为是一个好习惯。更多信息参见第 7.7 节。

### 7.2.1.4. 表函数

表函数是那些生成一个行集合的函数，这个集合可以是由基本数据类型(标量类型)组成， 也可以是由复合数据类型(表的行)组成。他们的用法类似一个表、视图、或 `FROM` 子句里的子查询。表函数返回的字段可以像一个表、视图、或者子查询的字段那样包含在 `SELECT`,`JOIN`,`WHERE`子句里。

使用`ROWS FROM`语法也可以组合表函数，结果返回并行的字段； 这种情况下的结果行数是较大函数的结果，较小的结果填充null值匹配。

    function_call [WITH ORDINALITY] [[AS] table_alias [(column_alias [, ... ])]]
    ROWS FROM( function_call [, ... ] ) [WITH ORDINALITY] [[AS] table_alias [(column_alias [, ... ])]]

如果声明了`WITH ORDINALITY`子句，那么一个类型为 `bigint`的附加字段将被添加到函数结果字段中。 这一列数字从1开始，直到函数结果集的行数。（这是一个SQL标准语法对 `UNNEST ... WITH ORDINALITY`的概括。） 缺省的，序号字段名为`ordinality`，但是可以使用`AS` 子句赋给它一个不同的字段名。

任意数量的数组参数都可以调用特殊的表函数`UNNEST`， 并且它返回对象的字段数量，就像已经在每个参数上单独调用了 `UNNEST`(第 9.18 节)， 并且使用`ROWS FROM`构造组合了一样。

    UNNEST( array_expression [, ... ] ) [WITH ORDINALITY] [[AS] table_alias [(column_alias [, ... ])]]

如果没有声明`table_alias`， 那么使用该函数的名字作为该表的名字；在`ROWS FROM()`构造的情况下， 使用第一个函数的名字。

如果没有提供字段别名，那么对于一个返回基本数据类型的函数来说， 字段名和该函数的名字相同。对于一个返回复合类型的函数来说， 结果字段得到的名字是该类型的属性名。

一些例子：

    CREATE TABLE foo (fooid int, foosubid int, fooname text);

    CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$
        SELECT * FROM foo WHERE fooid = $1;
    $$ LANGUAGE SQL;

    SELECT * FROM getfoo(1) AS t1;

    SELECT * FROM foo
        WHERE foosubid IN (
                            SELECT foosubid
                            FROM getfoo(foo.fooid) z
                            WHERE z.fooid = foo.fooid
                          );

    CREATE VIEW vw_getfoo AS SELECT * FROM getfoo(1);

    SELECT * FROM vw_getfoo;

有时侯，把一个函数定义成根据不同的调用方法可以返回不同的字段是很有用的。 为了支持这个，表函数可以声明为返回伪类型`record`。如果在查询里使用这样的函数， 那么我们必须在查询中声明预期的行结构，这样系统才知道如何分析和规划该查询。 这个语法看起来像：

    function_call [AS] alias (column_definition [, ... ])
    function_call AS [alias] (column_definition [, ... ])
    ROWS FROM( ... function_call AS (column_definition [, ... ]) [, ... ] )

当不使用`ROWS FROM()`语法时，`column_definition` 列表替换可能会被附加到`FROM`项的字段别名列表； 字段定义中的名字充当字段别名。当使用了`ROWS FROM()`语法时， `column_definition`可以单独附加到每个成员函数； 或者如果只有一个成员函数，并且没有`WITH ORDINALITY`子句， 那么`column_definition` 列表可以替换跟随`ROWS FROM()`的字段别名列表。

考虑这个例子：

    SELECT *
        FROM dblink('dbname=mydb', 'SELECT proname, prosrc FROM pg_proc')
          AS t1(proname name, prosrc text)
        WHERE proname LIKE 'bytea%';

dblink函数（dblink模块的一部分） 执行一个远程的查询。它声明为返回`record`，因为它可能会被用于任何类型的查询。 实际的字段集必须在调用它的查询中声明，这样分析器才知道类似`*` 这样的东西应该扩展成什么样子。

### 7.2.1.5. `LATERAL` 子查询

`FROM`子句中出现的子查询可以放在关键字`LATERAL`之前。 这样就允许它们引用通过前置`FROM`条目提供的字段。（如果没有`LATERAL`， 那么每个子查询都被认为是独立的并且不能交叉引用任何其他的`FROM`条目。）

`FROM`中出现的表函数也可以出现在关键字`LATERAL`之前， 但是对于函数来说，这个关键字是可选的；函数的参数在任何情况下都可以包含通过前置`FROM` 条目提供的字段。

`LATERAL`条目可以出现在`FROM`列表的顶级，或者在`JOIN`树中。 在后者的情况下，它在`JOIN`右侧时也可以参考左侧的条目。

当`FROM`包含`LATERAL`交叉引用时，评估收益如下： `FROM`条目的每行或多个`FROM`条目的行组提供交叉引用的字段， `LATERAL`条目被评估为使用行或行组的字段值。结果行像平常一样加入他们的计算行。 这些来自字段原表中的行或行组就这样重复。

一个`LATERAL`常见的例子是：

    SELECT * FROM foo, LATERAL (SELECT * FROM bar WHERE bar.id = foo.bar_id) ss;

这并不是特别有用的，因为它的结果正好和更传统做法的相同。

    SELECT * FROM foo, bar WHERE bar.id = foo.bar_id;

`LATERAL`当交叉引用字段对于加入的计算行是重要的时是主要有用的。 一个常见的应用是为一个set-returning函数提供一个参数值。例如，假设`vertices(polygon)` 返回一个多边形的顶点坐标，我们可以识别出多边形的顶点距离近的存储在一个表中：

    SELECT p1.id, p2.id, v1, v2
    FROM polygons p1, polygons p2,
         LATERAL vertices(p1.poly) v1,
         LATERAL vertices(p2.poly) v2
    WHERE (v1 <-> v2) < 10 AND p1.id != p2.id;

这条语句也可以写成：

    SELECT p1.id, p2.id, v1, v2
    FROM polygons p1 CROSS JOIN LATERAL vertices(p1.poly) v1,
         polygons p2 CROSS JOIN LATERAL vertices(p2.poly) v2
    WHERE (v1 <-> v2) < 10 AND p1.id != p2.id;

或者几个其他等价的形式。（就像之前提到的，`LATERAL`关键字在这个例子中不是必须的， 但是我们为了明确而使用它。）

`LEFT JOIN`对于`LATERAL`子查询来说往往是特别有用的， 所以即使`LATERAL`子查询不产生行，源行也将出现在结果中。例如， 如果`get_product_names()`返回一个制造商制造的产品名字， 但是一些在我们表中的制造商当前没有生产任何产品，我们可以像下面这样找出这些制造商：

    SELECT m.name
    FROM manufacturers m LEFT JOIN LATERAL get_product_names(m.id) pname ON true
    WHERE pname IS NULL;

## 7.2.2. `WHERE`子句

WHERE 子句子句的语法是：

    WHERE search_condition

这里的`search_condition`是一个返回类型为 `boolean` 的值表达式(参阅第 4.2 节)。

在完成对`FROM`子句的处理之后，生成的每一行都会按照搜索条件进行检查。 如果结果是真，那么该行保留在输出表中，否则(也就是结果是假或NULL)就把它抛弃。 搜索条件通常至少要引用一列在`FROM`子句里生成的列，这不是必须的， 但如果不这样的话，`WHERE`子句就没什么意义了。

> 注意: 内连接的连接条件既可以写在`WHERE`子句里也可以写在`JOIN`子句里。 比如，下面的表表达式是等效的：

>     FROM a, b WHERE a.id = b.id AND b.val > 5

> 和：

>     FROM a INNER JOIN b ON (a.id = b.id) WHERE b.val > 5

> 或者可能还有：

>     FROM a NATURAL JOIN b WHERE b.val > 5

> 你想用哪个只是风格问题。`FROM`子句里的`JOIN` 语法可能不那么容易移植到其它产品中。即使它是在SQL标准。对于外连接而言， 我们没有选择：连接条件必须在`FROM`子句中完成。 外连接的`ON`或`USING`子句不等于`WHERE`条件， 因为它导致最终结果中行的增(那些不匹配的输入行)和删。

这里是一些`WHERE`子句的例子：

    SELECT ... FROM fdt WHERE c1 > 5

    SELECT ... FROM fdt WHERE c1 IN (1, 2, 3)

    SELECT ... FROM fdt WHERE c1 IN (SELECT c1 FROM t2)

    SELECT ... FROM fdt WHERE c1 IN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10)

    SELECT ... FROM fdt WHERE c1 BETWEEN (SELECT c3 FROM t2 WHERE c2 = fdt.c1 + 10) AND 100

    SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 > fdt.c1)

在上面的例子里，`fdt`是从`FROM`子句中派生的表。 那些不符合`WHERE`子句的搜索条件的行将从`fdt`中删除。 请注意我们把标量子查询当做一个值表达式来用。就像其它查询一样， 子查询里也可以使用复杂的表表达式。同时还请注意子查询 是如何引用`fdt`的。把`c1`修饰成`fdt.c1` 只有在`c1`是该子查询生成的列名字时才是必须的， 但修饰列名字可以增加语句的准确性(即使有时不是必须的)。 这个例子就演示了字段名字范围如何从外层查询扩展到它的内层查询。

## 7.2.3. `GROUP BY`和`HAVING`子句

在通过了`WHERE`过滤器之后，生成的输入表可以继续用`GROUP BY` 子句进行分组，然后用`HAVING`子句选取一些分组行。

    SELECT select_list
        FROM ...
        [WHERE ...]
        GROUP BY grouping_column_reference [, grouping_column_reference]...

GROUP BY 子句 子句用于将一个表中所有列出的字段值都相等的行分成一组。 字段列出的顺序没什么关系。 效果是将每个拥有相同值的行集合并为一组，代表该组中的所有行。 这样就可以删除输出里的重复，和/或计算应用于这些组的聚合。 比如：

    => SELECT * FROM test1;
     x | y
    ---+---
     a | 3
     c | 2
     b | 5
     a | 1
    (4 rows)

    => SELECT x FROM test1 GROUP BY x;
     x
    ---
     a
     b
     c
    (3 rows)

在第二个查询里，我们不能写成`SELECT * FROM test1 GROUP BY x`， 因为字段`y`里没有哪个值可以和每个组关联起来。 被分组的字段可以在选择列表中引用是因为它们每个组都有单一的数值。

通常，如果一个表被分了组，不在`GROUP BY`中列出的字段只能在总表达式中被引用。 一个带聚合表达式的例子是：

    => SELECT x, sum(y) FROM test1 GROUP BY x;
     x | sum
    ---+-----
     a |   4
     b |   5
     c |   2
    (3 rows)

这里的`sum`是一个聚合函数，它在组上计算总和。 有关可用的聚合函数的更多信息可以在第 9.20 节中找到。

> 提示: 没有有效的聚合表达式分组可以计算一列中不同值的设置。 这个可以通过`DISTINCT`子句来实现(参考第 7.3.3 节).

这里是另外一个例子：它计算每种产品的总销售额(而不是所有产品的总销售额)。

    SELECT product_id, p.name, (sum(s.units) * p.price) AS sales
        FROM products p LEFT JOIN sales s USING (product_id)
        GROUP BY product_id, p.name, p.price;

在这个例子里，字段`product_id`，`p.name` 和`p.price`必须在`GROUP BY`子句里， 因为它们都在查询选择列表里被引用了（但见下文）。`s.units`字段不必在 `GROUP BY`列表里，因为它只是在一个聚合表达式(`sum(...)`)里使用， 它代表一组产品的销售总额。对于每种产品，这个查询都返回一个该产品的总销售额。

如果产品表是这样设置的，就说`product_id`是主键， 那么它足够在上面的例子中对`product_id`分组， 因为名字和价格将会函数依赖于产品ID， 这样将不会在返回每个产品ID组时有名字和价格的分歧。

在严格的SQL里，`GROUP BY`只能对源表的列进行分组，但PostgreSQL 把这个扩展为也允许`GROUP BY`对选择列表中的字段进行分组。 也允许对值表达式进行分组，而不仅仅是简单的字段。

如果一个表已经用`GROUP BY`分了组， 然后你又只对其中的某些组感兴趣，那么就可以用`HAVING`子句筛选分组。 必须像`WHERE`子句，从结果中消除组，语法是：

    SELECT select_list FROM ... [WHERE ...] GROUP BY ... HAVING boolean_expression

在`HAVING`子句中的表达式可以引用分组的表达式和未分组的表达式 (后者必须涉及一个聚合函数)。

例子：

    => SELECT x, sum(y) FROM test1 GROUP BY x HAVING sum(y) > 3;
     x | sum
    ---+-----
     a |   4
     b |   5
    (2 rows)

    => SELECT x, sum(y) FROM test1 GROUP BY x HAVING x < 'c';
     x | sum
    ---+-----
     a |   4
     b |   5
    (2 rows)

然后是一个更现实的例子：

    SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit
        FROM products p LEFT JOIN sales s USING (product_id)
        WHERE s.date > CURRENT_DATE - INTERVAL '4 weeks'
        GROUP BY product_id, p.name, p.price, p.cost
        HAVING sum(p.price * s.units) > 5000;

在上面的例子里，`WHERE`子句根据未分组的字段选择数据行 (表达式只是对那些最近四周发生的销售为真)。而`HAVING` 子句在分组之后选择那些销售总额超过5000的组。 请注意聚合表达式不需要在查询中的所有地方都一样。

如果一个查询调用了聚合函数，但没有`GROUP BY`子句，分组仍然发生： 结果是单一组行（或者如果单一行被`HAVING`所淘汰，那么也许没有行）。 同样，它包含一个`HAVING`子句，甚至没有任何聚合函数的调用或`GROUP BY`子句。

## 7.2.4. 窗口函数处理

如果查询包含窗口函数(参考第 3.5 节，第 9.21 节 和第 4.2.8 节)，这些函数在执行了分组、聚合和`HAVING` 过滤之后被评估。也就是说，如果查询使用任何的聚合、`GROUP BY`或`HAVING`， 那么由窗口函数发现的行是该组行而不是从`FROM`/`WHERE`得到的原始表行。

当多个窗口函数被使用的时候，所有在它们的窗口定义里依照语法地等效于 `PARTITION BY`和`ORDER BY`子句的窗口函数保证在同一个过去的数据里被评估。 因此它们将看到同样的排序， 即使`ORDER BY`不唯一确定一个排序。然而，不确保所做出的关于评价的功能有不同的 `PARTITION BY`或`ORDER BY`规范。（在这种情况下， 一个排序步骤通常需要在窗口函数评估之间传递，并且不保证行的排序看似跟`ORDER BY`等效。）

目前，窗口函数总是需要分类数据，所以查询输出将按照一个或另一个窗口函数的 `PARTITION BY`/`ORDER BY`子句。它不是说依赖于此。 如果你想要确保结果是按特定的方式分类那么使用显式的顶级ORDER BY子句。

上一页 | 起始页 | 下一页
概述 | 上一级 | 选择列表