SELECT

FROM 子句

FROM 子句为 SELECT 声明一个或多个源表． 如果声明了多个源表，则概念上结果是所有源表所有行的迪卡尔积 --- 不过通常会增加限制条件以把返回的行限制为迪卡尔积的一个小子集．

如果 FROM 项是一个简单表名字，它隐含包括来自该表子表（继承子表）的行． ONLY 将消除从该表的子表来的行． 在 PostgreSQL 7.1 以前，这是缺省结果， 而获取子表的行是通过在表名后面附加 * 实现的． 这种老式性质可以通过命令 SET SQL_Inheritance TO OFF; 获取．

FROM 项也可以是一个加了圆括弧的子查询 （请注意子查询需要一个别名子句！）． 这个特性非常实用，因为这是在一条查询中获得多层分组， 聚集，或者排序的唯一方法．

最后，FROM 项可以是一条 JOIN 子句，它把两个简单的 FROM 项组合 在一起．（必要时使用圆括弧来描述嵌套顺序．）

CROSS JOIN 或 INNER JOIN 是简单的迪卡尔积， 和你在顶层 FROM 里列出这两个项得到的一样． CROSS JOIN 等效于 INNER JOIN ON (TRUE)，也就是说， 不会有任何行被条件删除．这些连接类型只是符号上的便利， 因为它们做得一点不比你只利用 FROM 和 WHERE 来的多．

LEFT OUTER JOIN 返回所有符合条件的迪卡尔积 （也就是说，所有符合它的 ON 条件的组合了的行），另外加上 所有没有右手边行符合 ON 条件的左手边表中的行． 这样的左手边行通过向右手边行插入 NULL 扩展为全长． 请注意，当判断哪些行合格的时候，只考虑 JOIN 自己的 ON 或 USING． 然后才考虑外层的 ON 或 WHERE 条件．

相反， RIGHT OUTER JOIN 返回所有连接的行， 另外加上所有未匹配右手边行（左手边插入 NULL 扩展为全长）． 这个字句只是符号方便，因为你可以调换左右输入而改用 LEFT OUTER JOIN．

FULL OUTER JOIN 返回所有连接行，加上所有未匹配的左手边行 （右边插入 NULL 扩展为全长）， 再加上所有未匹配的右手边行（左手边插入 NULL 扩展为全长）．

除了CROSS JOIN 以外的所有 JOIN 类型，你必须写 ON join_condition， USING ( join_column_list )， 和 NATURAL 中的一个． 大多数情况下会是 ON：你可以写涉及两个连接表的任何条件表达式． USING 字段列表 (a, b, ...） 是 ON 条件 left_table.a = right_table.a AND left_table.b = right_table.b ... 的缩写． 另外，USING 假设两对等式中只有一个包含在 JOIN 输出中，而不是两个． NATURAL 是提及表中所有相似名字字段的 USING 列表的缩写．

WHERE 子句

可选的 WHERE 条件有如下常见的形式：

WHERE boolean_expr
    

boolean_expr 可以包含任意个得出布尔值的表达式。通常表达式会是

     expr cond_op expr
    

或

     log_op expr
    

这里 cond_op 可以是： =，<，<=， >，>= 或 <>， 或条件操作符象 ALL，ANY，IN，LIKE 等，或者用户定义的操作符，而 log_op 可以为 ： AND，OR，NOT． SELECT 将忽略所有 WHERE 条件不为 TRUE 的行．

GROUP BY 子句

GROUP BY 声明一个分了组的表，该表源于应用使用下面的子句：

GROUP BY expression [, ...]
    

GROUP BY 将把所有在组合了的列上共享同样的值的行压缩成一行。 如果存在聚集函数，这些聚集函数将计算每个组的所有行，并且为 每个组计算一个独立的值（如果没有 GROUP BY， 聚集函数对选出的所有行计算出一个数值）。存在 GROUP BY 时，除了在聚集函数 里面，SELECT 输出表达式对任何非组合列的引用都是非法的， 因为对一个非组合列会有多于一个可能的返回值。

一个在 GROUP BY 里面的条目还可以是输出列的名称或者序号 （SELECT 表达式）， 或者是一个从输入列的数值形成的任意表达式．当存在语义模糊时， 一个 GROUP BY 名称将被解释成一个输入列/字段名称而不是一个输出列/字段名称．

HAVING 子句

可选的 HAVING 条件有如下形式：

HAVING boolean_expr
    

这里 boolean_expr 和为 WHERE 子句里声明的相同．

HAVING 子句声明一个从前面的子句的结果集中去除了一些不符合 boolean_expr. 组后分组的表．HAVING 与 WHERE 不同：WHERE 在应用 GROUP BY 之前过滤出单独的行，而 HAVING 过滤由 GROUP BY 创建的行．

在 boolean_expr 里引用的每个列/字段应该清晰地指明一个组的列/字段， 除非引用在一个聚集函数里。

ORDER BY 子句

ORDER BY expression [ ASC | DESC | USING operator ] [, ...]
    

一个 ORDER BY 项可以是一个输出列(SELECT 表达式)的名字或者序数， 或者它也可以是任何来自输入列值形成的表达式． 在出现混淆的场合下，ORDER BY 名字将被解释成一个输出名字．

序数指的是列/字段按顺序（从左到右）的位置． 这个特性可以使得对没有一个唯一名称的列/字段的排序成为可能． 这一点可能永远没有用， 因为总是可以通过AS 子句给一个要计算的列/字段赋予一个名称，例如：

SELECT title, date_prod + 1 AS newlen FROM films ORDER BY newlen;
    

还可以 ORDER BY 任意表达式（一个对 SQL92 的扩展）， 包括那些没有出现在 SELECT 结果列表里面的域。 因此下面的语句现在是合法的：

SELECT name FROM distributors ORDER BY code;
    

这个特性的一个局限就是应用于 UNION，INTERSECT，或者 EXCEPT 查询 的 ORDER BY 子句只能在一个输出字段名或者数字上声明， 而不能在一个表达式上声明．

请注意如果一个 ORDER BY 条目是一个匹配结果列和输入列的简单名称， ORDER BY 将把它解释成结果列名称． 这和 GROUP BY 在同样情况下做的选择正相反． 这样的不一致是由 SQL92 标准强制的．

我们可以给ORDER BY 子句里每个列/字段加一个关键字 DESC （降序）或 ASC（升序）．如果不声明，ASC 是缺省． 我们还可以声明一个排序操作符来实现排序。 ASC 等效于使用 '<' 而 DESC 等效于使用 '>'。

在一个域里，空值排序时排在其它数值前面．换句话说，升序排序时， 空值排在末尾，而降序排序时空值排在开头．

字符类型的数据是按照区域相关的字符集顺序排序的，这个区域是在数据库 集群初始化的时候建立的。

UNION 子句

table_query UNION [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } [ { OFFSET | , } start ]]
    

这里 table_query 表明任何没有 ORDER BY，FOR UPDATE，或者 LIMIT 子句的选择表达式． （如果用圆括弧包围，ORDER BY 和 LIMIT 可以放在子表达式里． 如果没有圆括弧，这些子句将交给 UNION 的结果使用， 而不是给它们右手边的输入表达式．）

UNION 操作符的结果集是那些涉及到的所有查询所返回结果的集合。 两个做为 UNION 直接操作数的 SELECT 必须生成相同数目的字段， 并且对应的字段必须有兼容的数据类型。

缺省地，UNION 的结果不包含任何重复的行，除非声明了 ALL 子句． ALL 制止了消除重复的动作．

同一 SELECT 语句中的多个 UNION 操作符是从左向右计算的， 除非用圆括弧进行了标识）．

目前，FOR UPDATE 不能在 UNION 的结果或输入中声明．

INTERSECT 子句

table_query INTERSECT [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } ]
    [ OFFSET start ]
    

这里 table_query 声明任何没有 ORDER BY，FOR UPDATE，或者 LIMIT 子句的选择表达式。

INTERSECT 类似 UNION，只不过它给出在两个查询中都出现的行， 而不是两个查询的所有行．

INTERSECT 的结果不包含任何重复行，除非你声明了 ALL 选项． 用了 ALL 以后，一个在 L 里有 m 个重复而在 R 里有 n 个重复 的行将出现 min(m,n) 次．

除非用圆括号指明顺序， 同一 SELECT 语句中的多个 INTERSECT 操作符是从左向右计算的。 INTERSECT 比 UNION 绑定得更紧 --- 也就是说 A UNION B INTERSECT C 将读做 A UNION (B INTERSECT C)，除非你用圆括弧声明．

EXCEPT 子句

table_query EXCEPT [ ALL ] table_query
    [ ORDER BY expression [ ASC | DESC | USING operator ] [, ...] ]
    [ LIMIT { count | ALL } ]
    [ OFFSET start ]
    

这里 table_query 声明任何没有 ORDER BY，FOR UPDATE，或者 LIMIT 子句的选择表达式。

EXCEPT 类似于 UNION，只不过 EXCEPT 给出存在于左边查询输出而不存在于右边查询输出的行。

EXCEPT 的结果不包含任何重复的行，除非声明了 ALL 选项． 使用ALL时，一个在 L 中有 m 个重复而在 R 中有 n 个重复的行 将出现 max(m-n,0) 次．

除非用圆括弧指明顺序， 同一 SELECT 语句中的多个 EXCEPT 操作符是从左向右计算的。 EXCEPT 和 UNION 绑定级别相同．

LIMIT 子句

    LIMIT { count | ALL }
    OFFSET start 
    

这里 count 声明返回的最大行数，而 start 声明开始返回行之前忽略的行数。

LIMIT 允许你检索由查询其他部分生成的行的某一部分。 如果给出了限制计数，那么返回的行数不会超过哪个限制。 如果给出了一个偏移量，那么开始返回行之前会忽略那个数量的行。

在使用 LIMIT 时， 一个好习惯是使用一个 ORDER BY 子句把结果行限制成一个唯一的顺序。 否则你会得到无法预料的查询返回的子集 --- 你可能想要第十行到第二十行， 但以什么顺序？除非你声明 ORDER BY，否则你不知道什么顺序。

从 PostgreSQL 7.0 开始， 查询优化器在生成查询规划时把 LIMIT 考虑进去了， 所以你很有可能因给出的 LIMIT 和 OFFSET 值不同而得到不同的 规划（生成不同的行序）。 因此用不同的 LIMIT/OFFSET 值选择不同的查询结果的子集 将不会产生一致的结果， 除非你用 ORDER BY 强制生成一个可预计的结果顺序。 这可不是毛病；这是 SQL 生来的特点，因为除非用了 ORDER BYE 约束顺序， SQL 不保证查询生成的结果有任何特定的顺序。

FOR UPDATE 子句

    FOR UPDATE [ OF tablename [, ...] ]
    

FOR UPDATE 令那些被查询检索出来的行被锁住，就像要更新一样。 这样就避免它们在当前事务结束前被其它事务修改或者删除； 也就是说，其它视图 UPDATE，DELETE， 或者 SELECT FOR UPDATE 这些行得事务将被阻塞， 直到当前事务结束。同样，如果一个来自其它事务的 UPDATE， DELETE，或者 SELECT FOR UPDATE 已经锁住了某个或某些选定的行，SELECT FOR UPDATE 将等到那些事务结束，并且将随后锁住并返回更新的行 （或者不返回行，如果行已经被删除）。更多的讨论参阅 Chapter 9 in PostgreSQL 7.3 用户手册。

如果特定的表在 FOR UPDATE 中命名，那么只有来自这些表中的行才 被锁住；任何在 SELECT 中使用的其它表都只是 和平常一样读取。

FOR UPDATE 不能在那些反会的行不能清晰的表示独立的表数据行的环境； 比如，它不能和聚集一起使用。

FOR UPDATE 可以在 LIMIT 前面出现，主要是为了和 7.3 之前的应用兼容。 不过，它在 LIMIT 后面执行更高效，因此我们建议放在后面。

扩展

PostgreSQL 允许我们在一个查询里省略 FROM 子句。 这个特性是从最初的 PostQuel 查询语言里保留下来的 它的最直接用途就是计算简单的常量表达式的结果：

SELECT 2+2;

 ?column?
----------
        4
  

其它有些 DBMS 不能这么做，除非引入一个单行的伪表做 select 的 from． 这个特性的另外一个不太明显的用途是把一个普通的从一个或多个表的 select 缩写：

SELECT distributors.* WHERE distributors.name = 'Westward';

 did | name
-----+----------
 108 | Westward
  

这样也可以运行是因为我们给查询中引用了但没有在 FROM 中提到的每个表 都加了一个隐含的 FROM 项．尽管这是个很方便的写法，但它却容易误用． 比如，下面的查询

SELECT distributors.* FROM distributors d;
  

可能就是个错误；用户最有可能的意思是

SELECT d.* FROM distributors d;
  

而不是下面的他实际上得到的无约束的连接

SELECT distributors.* FROM distributors d, distributors distributors;
  

为了帮助检测这种错误， PostgreSQL 7.1 以及以后的版本将在你使用一条即有隐含 FROM 特性 又有明确的 FORM 子句的查询的时候给出警告．

SQL92

 
table_query UNION [ALL]
    [CORRESPONDING [BY (column [,...])]]
    table_query