Baoding-FenShuaJiang
/
Green_GoodERP18_FSJ_Standard
关注 1
点赞 0
百科 捐赠
gooderp18绿色标准版
您最多选择25个主题 主题必须以字母或数字开头，可以包含连字符 (-)，并且长度不得超过35个字符
分支: master
分支列表 标签列表
${ item.name }
创建分支 ${ searchTerm }
从 'master'
${ noResults }
Green_GoodERP18_FSJ_Standard/PostgreSQL/doc/postgresql/html/queries-table-expressions.html

962 行
57KB
原始文件 永久链接 Blame 文件历史 

  1. <?xml version="1.0" encoding="UTF-8" standalone="no"?>

  2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>7.2. Table Expressions</title><link rel="stylesheet" type="text/css" href="stylesheet.css" /><link rev="made" href="pgsql-docs@lists.postgresql.org" /><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /><link rel="prev" href="queries-overview.html" title="7.1. Overview" /><link rel="next" href="queries-select-lists.html" title="7.3. Select Lists" /></head><body><div xmlns="http://www.w3.org/TR/xhtml1/transitional" class="navheader"><table width="100%" summary="Navigation header"><tr><th colspan="5" align="center">7.2. Table Expressions</th></tr><tr><td width="10%" align="left"><a accesskey="p" href="queries-overview.html" title="7.1. Overview">Prev</a> </td><td width="10%" align="left"><a accesskey="u" href="queries.html" title="Chapter 7. Queries">Up</a></td><th width="60%" align="center">Chapter 7. Queries</th><td width="10%" align="right"><a accesskey="h" href="index.html" title="PostgreSQL 12.4 Documentation">Home</a></td><td width="10%" align="right"> <a accesskey="n" href="queries-select-lists.html" title="7.3. Select Lists">Next</a></td></tr></table><hr></hr></div><div class="sect1" id="QUERIES-TABLE-EXPRESSIONS"><div class="titlepage"><div><div><h2 class="title" style="clear: both">7.2. Table Expressions</h2></div></div></div><div class="toc"><dl class="toc"><dt><span class="sect2"><a href="queries-table-expressions.html#QUERIES-FROM">7.2.1. The <code class="literal">FROM</code> Clause</a></span></dt><dt><span class="sect2"><a href="queries-table-expressions.html#QUERIES-WHERE">7.2.2. The <code class="literal">WHERE</code> Clause</a></span></dt><dt><span class="sect2"><a href="queries-table-expressions.html#QUERIES-GROUP">7.2.3. The <code class="literal">GROUP BY</code> and <code class="literal">HAVING</code> Clauses</a></span></dt><dt><span class="sect2"><a href="queries-table-expressions.html#QUERIES-GROUPING-SETS">7.2.4. <code class="literal">GROUPING SETS</code>, <code class="literal">CUBE</code>, and <code class="literal">ROLLUP</code></a></span></dt><dt><span class="sect2"><a href="queries-table-expressions.html#QUERIES-WINDOW">7.2.5. Window Function Processing</a></span></dt></dl></div><a id="id-1.5.6.6.2" class="indexterm"></a><p>

  3.    A <em class="firstterm">table expression</em> computes a table.  The

  4.    table expression contains a <code class="literal">FROM</code> clause that is

  5.    optionally followed by <code class="literal">WHERE</code>, <code class="literal">GROUP BY</code>, and

  6.    <code class="literal">HAVING</code> clauses.  Trivial table expressions simply refer

  7.    to a table on disk, a so-called base table, but more complex

  8.    expressions can be used to modify or combine base tables in various

  9.    ways.

  10.   </p><p>

  11.    The optional <code class="literal">WHERE</code>, <code class="literal">GROUP BY</code>, and

  12.    <code class="literal">HAVING</code> clauses in the table expression specify a

  13.    pipeline of successive transformations performed on the table

  14.    derived in the <code class="literal">FROM</code> clause.  All these transformations

  15.    produce a virtual table that provides the rows that are passed to

  16.    the select list to compute the output rows of the query.

  17.   </p><div class="sect2" id="QUERIES-FROM"><div class="titlepage"><div><div><h3 class="title">7.2.1. The <code class="literal">FROM</code> Clause</h3></div></div></div><p>

  18.     The <a class="xref" href="sql-select.html#SQL-FROM" title="FROM Clause"><code class="literal">FROM</code> Clause</a> derives a

  19.     table from one or more other tables given in a comma-separated

  20.     table reference list.

  21. </p><pre class="synopsis">

  22. FROM <em class="replaceable"><code>table_reference</code></em> [<span class="optional">, <em class="replaceable"><code>table_reference</code></em> [<span class="optional">, ...</span>]</span>]

  23. </pre><p>

  24. 

  25.     A table reference can be a table name (possibly schema-qualified),

  26.     or a derived table such as a subquery, a <code class="literal">JOIN</code> construct, or

  27.     complex combinations of these.  If more than one table reference is

  28.     listed in the <code class="literal">FROM</code> clause, the tables are cross-joined

  29.     (that is, the Cartesian product of their rows is formed; see below).

  30.     The result of the <code class="literal">FROM</code> list is an intermediate virtual

  31.     table that can then be subject to

  32.     transformations by the <code class="literal">WHERE</code>, <code class="literal">GROUP BY</code>,

  33.     and <code class="literal">HAVING</code> clauses and is finally the result of the

  34.     overall table expression.

  35.    </p><a id="id-1.5.6.6.5.3" class="indexterm"></a><p>

  36.     When a table reference names a table that is the parent of a

  37.     table inheritance hierarchy, the table reference produces rows of

  38.     not only that table but all of its descendant tables, unless the

  39.     key word <code class="literal">ONLY</code> precedes the table name.  However, the

  40.     reference produces only the columns that appear in the named table

  41.     — any columns added in subtables are ignored.

  42.    </p><p>

  43.     Instead of writing <code class="literal">ONLY</code> before the table name, you can write

  44.     <code class="literal">*</code> after the table name to explicitly specify that descendant

  45.     tables are included.  There is no real reason to use this syntax any more,

  46.     because searching descendant tables is now always the default behavior.

  47.     However, it is supported for compatibility with older releases.

  48.    </p><div class="sect3" id="QUERIES-JOIN"><div class="titlepage"><div><div><h4 class="title">7.2.1.1. Joined Tables</h4></div></div></div><a id="id-1.5.6.6.5.6.2" class="indexterm"></a><p>

  49.      A joined table is a table derived from two other (real or

  50.      derived) tables according to the rules of the particular join

  51.      type.  Inner, outer, and cross-joins are available.

  52.      The general syntax of a joined table is

  53. </p><pre class="synopsis">

  54. <em class="replaceable"><code>T1</code></em> <em class="replaceable"><code>join_type</code></em> <em class="replaceable"><code>T2</code></em> [<span class="optional"> <em class="replaceable"><code>join_condition</code></em> </span>]

  55. </pre><p>

  56.      Joins of all types can be chained together, or nested: either or

  57.      both <em class="replaceable"><code>T1</code></em> and

  58.      <em class="replaceable"><code>T2</code></em> can be joined tables.  Parentheses

  59.      can be used around <code class="literal">JOIN</code> clauses to control the join

  60.      order.  In the absence of parentheses, <code class="literal">JOIN</code> clauses

  61.      nest left-to-right.

  62.     </p><div class="variablelist"><p class="title"><strong>Join Types</strong></p><dl class="variablelist"><dt><span class="term">Cross join

  63.       <a id="id-1.5.6.6.5.6.4.2.1.1" class="indexterm"></a>

  64. 

  65.       <a id="id-1.5.6.6.5.6.4.2.1.2" class="indexterm"></a>

  66.       </span></dt><dd><pre class="synopsis">

  67. <em class="replaceable"><code>T1</code></em> CROSS JOIN <em class="replaceable"><code>T2</code></em>

  68. </pre><p>

  69.         For every possible combination of rows from

  70.         <em class="replaceable"><code>T1</code></em> and

  71.         <em class="replaceable"><code>T2</code></em> (i.e., a Cartesian product),

  72.         the joined table will contain a

  73.         row consisting of all columns in <em class="replaceable"><code>T1</code></em>

  74.         followed by all columns in <em class="replaceable"><code>T2</code></em>.  If

  75.         the tables have N and M rows respectively, the joined

  76.         table will have N * M rows.

  77.        </p><p>

  78.         <code class="literal">FROM <em class="replaceable"><code>T1</code></em> CROSS JOIN

  79.         <em class="replaceable"><code>T2</code></em></code> is equivalent to

  80.         <code class="literal">FROM <em class="replaceable"><code>T1</code></em> INNER JOIN

  81.         <em class="replaceable"><code>T2</code></em> ON TRUE</code> (see below).

  82.         It is also equivalent to

  83.         <code class="literal">FROM <em class="replaceable"><code>T1</code></em>,

  84.         <em class="replaceable"><code>T2</code></em></code>.

  85.         </p><div class="note"><h3 class="title">Note</h3><p>

  86.          This latter equivalence does not hold exactly when more than two

  87.          tables appear, because <code class="literal">JOIN</code> binds more tightly than

  88.          comma.  For example

  89.          <code class="literal">FROM <em class="replaceable"><code>T1</code></em> CROSS JOIN

  90.          <em class="replaceable"><code>T2</code></em> INNER JOIN <em class="replaceable"><code>T3</code></em>

  91.          ON <em class="replaceable"><code>condition</code></em></code>

  92.          is not the same as

  93.          <code class="literal">FROM <em class="replaceable"><code>T1</code></em>,

  94.          <em class="replaceable"><code>T2</code></em> INNER JOIN <em class="replaceable"><code>T3</code></em>

  95.          ON <em class="replaceable"><code>condition</code></em></code>

  96.          because the <em class="replaceable"><code>condition</code></em> can

  97.          reference <em class="replaceable"><code>T1</code></em> in the first case but not

  98.          the second.

  99.         </p></div><p>

  100.        </p></dd><dt><span class="term">Qualified joins

  101.       <a id="id-1.5.6.6.5.6.4.3.1.1" class="indexterm"></a>

  102. 

  103.       <a id="id-1.5.6.6.5.6.4.3.1.2" class="indexterm"></a>

  104.       </span></dt><dd><pre class="synopsis">

  105. <em class="replaceable"><code>T1</code></em> { [<span class="optional">INNER</span>] | { LEFT | RIGHT | FULL } [<span class="optional">OUTER</span>] } JOIN <em class="replaceable"><code>T2</code></em> ON <em class="replaceable"><code>boolean_expression</code></em>

  106. <em class="replaceable"><code>T1</code></em> { [<span class="optional">INNER</span>] | { LEFT | RIGHT | FULL } [<span class="optional">OUTER</span>] } JOIN <em class="replaceable"><code>T2</code></em> USING ( <em class="replaceable"><code>join column list</code></em> )

  107. <em class="replaceable"><code>T1</code></em> NATURAL { [<span class="optional">INNER</span>] | { LEFT | RIGHT | FULL } [<span class="optional">OUTER</span>] } JOIN <em class="replaceable"><code>T2</code></em>

  108. </pre><p>

  109.         The words <code class="literal">INNER</code> and

  110.         <code class="literal">OUTER</code> are optional in all forms.

  111.         <code class="literal">INNER</code> is the default;

  112.         <code class="literal">LEFT</code>, <code class="literal">RIGHT</code>, and

  113.         <code class="literal">FULL</code> imply an outer join.

  114.        </p><p>

  115.         The <em class="firstterm">join condition</em> is specified in the

  116.         <code class="literal">ON</code> or <code class="literal">USING</code> clause, or implicitly by

  117.         the word <code class="literal">NATURAL</code>.  The join condition determines

  118.         which rows from the two source tables are considered to

  119.         <span class="quote">“<span class="quote">match</span>”</span>, as explained in detail below.

  120.        </p><p>

  121.         The possible types of qualified join are:

  122. 

  123.        </p><div class="variablelist"><dl class="variablelist"><dt><span class="term"><code class="literal">INNER JOIN</code></span></dt><dd><p>

  124.            For each row R1 of T1, the joined table has a row for each

  125.            row in T2 that satisfies the join condition with R1.

  126.           </p></dd><dt><span class="term"><code class="literal">LEFT OUTER JOIN</code>

  127.          <a id="id-1.5.6.6.5.6.4.3.2.4.1.2.1.2" class="indexterm"></a>

  128. 

  129.          <a id="id-1.5.6.6.5.6.4.3.2.4.1.2.1.3" class="indexterm"></a>

  130.          </span></dt><dd><p>

  131.            First, an inner join is performed.  Then, for each row in

  132.            T1 that does not satisfy the join condition with any row in

  133.            T2, a joined row is added with null values in columns of

  134.            T2.  Thus, the joined table always has at least

  135.            one row for each row in T1.

  136.           </p></dd><dt><span class="term"><code class="literal">RIGHT OUTER JOIN</code>

  137.          <a id="id-1.5.6.6.5.6.4.3.2.4.1.3.1.2" class="indexterm"></a>

  138. 

  139.          <a id="id-1.5.6.6.5.6.4.3.2.4.1.3.1.3" class="indexterm"></a>

  140.          </span></dt><dd><p>

  141.            First, an inner join is performed.  Then, for each row in

  142.            T2 that does not satisfy the join condition with any row in

  143.            T1, a joined row is added with null values in columns of

  144.            T1.  This is the converse of a left join: the result table

  145.            will always have a row for each row in T2.

  146.           </p></dd><dt><span class="term"><code class="literal">FULL OUTER JOIN</code></span></dt><dd><p>

  147.            First, an inner join is performed.  Then, for each row in

  148.            T1 that does not satisfy the join condition with any row in

  149.            T2, a joined row is added with null values in columns of

  150.            T2.  Also, for each row of T2 that does not satisfy the

  151.            join condition with any row in T1, a joined row with null

  152.            values in the columns of T1 is added.

  153.           </p></dd></dl></div><p>

  154.        </p><p>

  155.         The <code class="literal">ON</code> clause is the most general kind of join

  156.         condition: it takes a Boolean value expression of the same

  157.         kind as is used in a <code class="literal">WHERE</code> clause.  A pair of rows

  158.         from <em class="replaceable"><code>T1</code></em> and <em class="replaceable"><code>T2</code></em> match if the

  159.         <code class="literal">ON</code> expression evaluates to true.

  160.        </p><p>

  161.         The <code class="literal">USING</code> clause is a shorthand that allows you to take

  162.         advantage of the specific situation where both sides of the join use

  163.         the same name for the joining column(s).  It takes a

  164.         comma-separated list of the shared column names

  165.         and forms a join condition that includes an equality comparison

  166.         for each one.  For example, joining <em class="replaceable"><code>T1</code></em>

  167.         and <em class="replaceable"><code>T2</code></em> with <code class="literal">USING (a, b)</code> produces

  168.         the join condition <code class="literal">ON <em class="replaceable"><code>T1</code></em>.a

  169.         = <em class="replaceable"><code>T2</code></em>.a AND <em class="replaceable"><code>T1</code></em>.b

  170.         = <em class="replaceable"><code>T2</code></em>.b</code>.

  171.        </p><p>

  172.         Furthermore, the output of <code class="literal">JOIN USING</code> suppresses

  173.         redundant columns: there is no need to print both of the matched

  174.         columns, since they must have equal values.  While <code class="literal">JOIN

  175.         ON</code> produces all columns from <em class="replaceable"><code>T1</code></em> followed by all

  176.         columns from <em class="replaceable"><code>T2</code></em>, <code class="literal">JOIN USING</code> produces one

  177.         output column for each of the listed column pairs (in the listed

  178.         order), followed by any remaining columns from <em class="replaceable"><code>T1</code></em>,

  179.         followed by any remaining columns from <em class="replaceable"><code>T2</code></em>.

  180.        </p><p>

  181.         <a id="id-1.5.6.6.5.6.4.3.2.8.1" class="indexterm"></a>

  182.         <a id="id-1.5.6.6.5.6.4.3.2.8.2" class="indexterm"></a>

  183.         Finally, <code class="literal">NATURAL</code> is a shorthand form of

  184.         <code class="literal">USING</code>: it forms a <code class="literal">USING</code> list

  185.         consisting of all column names that appear in both

  186.         input tables.  As with <code class="literal">USING</code>, these columns appear

  187.         only once in the output table.  If there are no common

  188.         column names, <code class="literal">NATURAL JOIN</code> behaves like

  189.         <code class="literal">JOIN ... ON TRUE</code>, producing a cross-product join.

  190.        </p><div class="note"><h3 class="title">Note</h3><p>

  191.          <code class="literal">USING</code> is reasonably safe from column changes

  192.          in the joined relations since only the listed columns

  193.          are combined.  <code class="literal">NATURAL</code> is considerably more risky since

  194.          any schema changes to either relation that cause a new matching

  195.          column name to be present will cause the join to combine that new

  196.          column as well.

  197.         </p></div></dd></dl></div><p>

  198.      To put this together, assume we have tables <code class="literal">t1</code>:

  199. </p><pre class="programlisting">

  200.  num | name

  201. -----+------

  202.    1 | a

  203.    2 | b

  204.    3 | c

  205. </pre><p>

  206.      and <code class="literal">t2</code>:

  207. </p><pre class="programlisting">

  208.  num | value

  209. -----+-------

  210.    1 | xxx

  211.    3 | yyy

  212.    5 | zzz

  213. </pre><p>

  214.      then we get the following results for the various joins:

  215. </p><pre class="screen">

  216. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 CROSS JOIN t2;</code></strong>

  217.  num | name | num | value

  218. -----+------+-----+-------

  219.    1 | a    |   1 | xxx

  220.    1 | a    |   3 | yyy

  221.    1 | a    |   5 | zzz

  222.    2 | b    |   1 | xxx

  223.    2 | b    |   3 | yyy

  224.    2 | b    |   5 | zzz

  225.    3 | c    |   1 | xxx

  226.    3 | c    |   3 | yyy

  227.    3 | c    |   5 | zzz

  228. (9 rows)

  229. 

  230. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 INNER JOIN t2 ON t1.num = t2.num;</code></strong>

  231.  num | name | num | value

  232. -----+------+-----+-------

  233.    1 | a    |   1 | xxx

  234.    3 | c    |   3 | yyy

  235. (2 rows)

  236. 

  237. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 INNER JOIN t2 USING (num);</code></strong>

  238.  num | name | value

  239. -----+------+-------

  240.    1 | a    | xxx

  241.    3 | c    | yyy

  242. (2 rows)

  243. 

  244. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 NATURAL INNER JOIN t2;</code></strong>

  245.  num | name | value

  246. -----+------+-------

  247.    1 | a    | xxx

  248.    3 | c    | yyy

  249. (2 rows)

  250. 

  251. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num;</code></strong>

  252.  num | name | num | value

  253. -----+------+-----+-------

  254.    1 | a    |   1 | xxx

  255.    2 | b    |     |

  256.    3 | c    |   3 | yyy

  257. (3 rows)

  258. 

  259. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 LEFT JOIN t2 USING (num);</code></strong>

  260.  num | name | value

  261. -----+------+-------

  262.    1 | a    | xxx

  263.    2 | b    |

  264.    3 | c    | yyy

  265. (3 rows)

  266. 

  267. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 RIGHT JOIN t2 ON t1.num = t2.num;</code></strong>

  268.  num | name | num | value

  269. -----+------+-----+-------

  270.    1 | a    |   1 | xxx

  271.    3 | c    |   3 | yyy

  272.      |      |   5 | zzz

  273. (3 rows)

  274. 

  275. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 FULL JOIN t2 ON t1.num = t2.num;</code></strong>

  276.  num | name | num | value

  277. -----+------+-----+-------

  278.    1 | a    |   1 | xxx

  279.    2 | b    |     |

  280.    3 | c    |   3 | yyy

  281.      |      |   5 | zzz

  282. (4 rows)

  283. </pre><p>

  284.     </p><p>

  285.      The join condition specified with <code class="literal">ON</code> can also contain

  286.      conditions that do not relate directly to the join.  This can

  287.      prove useful for some queries but needs to be thought out

  288.      carefully.  For example:

  289. </p><pre class="screen">

  290. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num AND t2.value = 'xxx';</code></strong>

  291.  num | name | num | value

  292. -----+------+-----+-------

  293.    1 | a    |   1 | xxx

  294.    2 | b    |     |

  295.    3 | c    |     |

  296. (3 rows)

  297. </pre><p>

  298.      Notice that placing the restriction in the <code class="literal">WHERE</code> clause

  299.      produces a different result:

  300. </p><pre class="screen">

  301. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM t1 LEFT JOIN t2 ON t1.num = t2.num WHERE t2.value = 'xxx';</code></strong>

  302.  num | name | num | value

  303. -----+------+-----+-------

  304.    1 | a    |   1 | xxx

  305. (1 row)

  306. </pre><p>

  307.      This is because a restriction placed in the <code class="literal">ON</code>

  308.      clause is processed <span class="emphasis"><em>before</em></span> the join, while

  309.      a restriction placed in the <code class="literal">WHERE</code> clause is processed

  310.      <span class="emphasis"><em>after</em></span> the join.

  311.      That does not matter with inner joins, but it matters a lot with outer

  312.      joins.

  313.     </p></div><div class="sect3" id="QUERIES-TABLE-ALIASES"><div class="titlepage"><div><div><h4 class="title">7.2.1.2. Table and Column Aliases</h4></div></div></div><a id="id-1.5.6.6.5.7.2" class="indexterm"></a><a id="id-1.5.6.6.5.7.3" class="indexterm"></a><p>

  314.      A temporary name can be given to tables and complex table

  315.      references to be used for references to the derived table in

  316.      the rest of the query.  This is called a <em class="firstterm">table

  317.      alias</em>.

  318.     </p><p>

  319.      To create a table alias, write

  320. </p><pre class="synopsis">

  321. FROM <em class="replaceable"><code>table_reference</code></em> AS <em class="replaceable"><code>alias</code></em>

  322. </pre><p>

  323.      or

  324. </p><pre class="synopsis">

  325. FROM <em class="replaceable"><code>table_reference</code></em> <em class="replaceable"><code>alias</code></em>

  326. </pre><p>

  327.      The <code class="literal">AS</code> key word is optional noise.

  328.      <em class="replaceable"><code>alias</code></em> can be any identifier.

  329.     </p><p>

  330.      A typical application of table aliases is to assign short

  331.      identifiers to long table names to keep the join clauses

  332.      readable.  For example:

  333. </p><pre class="programlisting">

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

  335. </pre><p>

  336.     </p><p>

  337.      The alias becomes the new name of the table reference so far as the

  338.      current query is concerned — it is not allowed to refer to the

  339.      table by the original name elsewhere in the query.  Thus, this is not

  340.      valid:

  341. </p><pre class="programlisting">

  342. SELECT * FROM my_table AS m WHERE my_table.a &gt; 5;    -- wrong

  343. </pre><p>

  344.     </p><p>

  345.      Table aliases are mainly for notational convenience, but it is

  346.      necessary to use them when joining a table to itself, e.g.:

  347. </p><pre class="programlisting">

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

  349. </pre><p>

  350.      Additionally, an alias is required if the table reference is a

  351.      subquery (see <a class="xref" href="queries-table-expressions.html#QUERIES-SUBQUERIES" title="7.2.1.3. Subqueries">Section 7.2.1.3</a>).

  352.     </p><p>

  353.      Parentheses are used to resolve ambiguities.  In the following example,

  354.      the first statement assigns the alias <code class="literal">b</code> to the second

  355.      instance of <code class="literal">my_table</code>, but the second statement assigns the

  356.      alias to the result of the join:

  357. </p><pre class="programlisting">

  358. SELECT * FROM my_table AS a CROSS JOIN my_table AS b ...

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

  360. </pre><p>

  361.     </p><p>

  362.      Another form of table aliasing gives temporary names to the columns of

  363.      the table, as well as the table itself:

  364. </p><pre class="synopsis">

  365. FROM <em class="replaceable"><code>table_reference</code></em> [<span class="optional">AS</span>] <em class="replaceable"><code>alias</code></em> ( <em class="replaceable"><code>column1</code></em> [<span class="optional">, <em class="replaceable"><code>column2</code></em> [<span class="optional">, ...</span>]</span>] )

  366. </pre><p>

  367.      If fewer column aliases are specified than the actual table has

  368.      columns, the remaining columns are not renamed.  This syntax is

  369.      especially useful for self-joins or subqueries.

  370.     </p><p>

  371.      When an alias is applied to the output of a <code class="literal">JOIN</code>

  372.      clause, the alias hides the original

  373.      name(s) within the <code class="literal">JOIN</code>.  For example:

  374. </p><pre class="programlisting">

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

  376. </pre><p>

  377.      is valid SQL, but:

  378. </p><pre class="programlisting">

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

  380. </pre><p>

  381.      is not valid; the table alias <code class="literal">a</code> is not visible

  382.      outside the alias <code class="literal">c</code>.

  383.     </p></div><div class="sect3" id="QUERIES-SUBQUERIES"><div class="titlepage"><div><div><h4 class="title">7.2.1.3. Subqueries</h4></div></div></div><a id="id-1.5.6.6.5.8.2" class="indexterm"></a><p>

  384.      Subqueries specifying a derived table must be enclosed in

  385.      parentheses and <span class="emphasis"><em>must</em></span> be assigned a table

  386.      alias name (as in <a class="xref" href="queries-table-expressions.html#QUERIES-TABLE-ALIASES" title="7.2.1.2. Table and Column Aliases">Section 7.2.1.2</a>).  For

  387.      example:

  388. </p><pre class="programlisting">

  389. FROM (SELECT * FROM table1) AS alias_name

  390. </pre><p>

  391.     </p><p>

  392.      This example is equivalent to <code class="literal">FROM table1 AS

  393.      alias_name</code>.  More interesting cases, which cannot be

  394.      reduced to a plain join, arise when the subquery involves

  395.      grouping or aggregation.

  396.     </p><p>

  397.      A subquery can also be a <code class="command">VALUES</code> list:

  398. </p><pre class="programlisting">

  399. FROM (VALUES ('anne', 'smith'), ('bob', 'jones'), ('joe', 'blow'))

  400.      AS names(first, last)

  401. </pre><p>

  402.      Again, a table alias is required.  Assigning alias names to the columns

  403.      of the <code class="command">VALUES</code> list is optional, but is good practice.

  404.      For more information see <a class="xref" href="queries-values.html" title="7.7. VALUES Lists">Section 7.7</a>.

  405.     </p></div><div class="sect3" id="QUERIES-TABLEFUNCTIONS"><div class="titlepage"><div><div><h4 class="title">7.2.1.4. Table Functions</h4></div></div></div><a id="id-1.5.6.6.5.9.2" class="indexterm"></a><a id="id-1.5.6.6.5.9.3" class="indexterm"></a><p>

  406.      Table functions are functions that produce a set of rows, made up

  407.      of either base data types (scalar types) or composite data types

  408.      (table rows).  They are used like a table, view, or subquery in

  409.      the <code class="literal">FROM</code> clause of a query. Columns returned by table

  410.      functions can be included in <code class="literal">SELECT</code>,

  411.      <code class="literal">JOIN</code>, or <code class="literal">WHERE</code> clauses in the same manner

  412.      as columns of a table, view, or subquery.

  413.     </p><p>

  414.      Table functions may also be combined using the <code class="literal">ROWS FROM</code>

  415.      syntax, with the results returned in parallel columns; the number of

  416.      result rows in this case is that of the largest function result, with

  417.      smaller results padded with null values to match.

  418.     </p><pre class="synopsis">

  419. <em class="replaceable"><code>function_call</code></em> [<span class="optional">WITH ORDINALITY</span>] [<span class="optional">[<span class="optional">AS</span>] <em class="replaceable"><code>table_alias</code></em> [<span class="optional">(<em class="replaceable"><code>column_alias</code></em> [<span class="optional">, ... </span>])</span>]</span>]

  420. ROWS FROM( <em class="replaceable"><code>function_call</code></em> [<span class="optional">, ... </span>] ) [<span class="optional">WITH ORDINALITY</span>] [<span class="optional">[<span class="optional">AS</span>] <em class="replaceable"><code>table_alias</code></em> [<span class="optional">(<em class="replaceable"><code>column_alias</code></em> [<span class="optional">, ... </span>])</span>]</span>]

  421. </pre><p>

  422.      If the <code class="literal">WITH ORDINALITY</code> clause is specified, an

  423.      additional column of type <code class="type">bigint</code> will be added to the

  424.      function result columns.  This column numbers the rows of the function

  425.      result set, starting from 1. (This is a generalization of the

  426.      SQL-standard syntax for <code class="literal">UNNEST ... WITH ORDINALITY</code>.)

  427.      By default, the ordinal column is called <code class="literal">ordinality</code>, but

  428.      a different column name can be assigned to it using

  429.      an <code class="literal">AS</code> clause.

  430.     </p><p>

  431.      The special table function <code class="literal">UNNEST</code> may be called with

  432.      any number of array parameters, and it returns a corresponding number of

  433.      columns, as if <code class="literal">UNNEST</code>

  434.      (<a class="xref" href="functions-array.html" title="9.18. Array Functions and Operators">Section 9.18</a>) had been called on each parameter

  435.      separately and combined using the <code class="literal">ROWS FROM</code> construct.

  436.     </p><pre class="synopsis">

  437. UNNEST( <em class="replaceable"><code>array_expression</code></em> [<span class="optional">, ... </span>] ) [<span class="optional">WITH ORDINALITY</span>] [<span class="optional">[<span class="optional">AS</span>] <em class="replaceable"><code>table_alias</code></em> [<span class="optional">(<em class="replaceable"><code>column_alias</code></em> [<span class="optional">, ... </span>])</span>]</span>]

  438. </pre><p>

  439.      If no <em class="replaceable"><code>table_alias</code></em> is specified, the function

  440.      name is used as the table name; in the case of a <code class="literal">ROWS FROM()</code>

  441.      construct, the first function's name is used.

  442.     </p><p>

  443.      If column aliases are not supplied, then for a function returning a base

  444.      data type, the column name is also the same as the function name.  For a

  445.      function returning a composite type, the result columns get the names

  446.      of the individual attributes of the type.

  447.     </p><p>

  448.      Some examples:

  449. </p><pre class="programlisting">

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

  451. 

  452. CREATE FUNCTION getfoo(int) RETURNS SETOF foo AS $$

  453.     SELECT * FROM foo WHERE fooid = $1;

  454. $$ LANGUAGE SQL;

  455. 

  456. SELECT * FROM getfoo(1) AS t1;

  457. 

  458. SELECT * FROM foo

  459.     WHERE foosubid IN (

  460.                         SELECT foosubid

  461.                         FROM getfoo(foo.fooid) z

  462.                         WHERE z.fooid = foo.fooid

  463.                       );

  464. 

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

  466. 

  467. SELECT * FROM vw_getfoo;

  468. </pre><p>

  469.     </p><p>

  470.      In some cases it is useful to define table functions that can

  471.      return different column sets depending on how they are invoked.

  472.      To support this, the table function can be declared as returning

  473.      the pseudo-type <code class="type">record</code>.  When such a function is used in

  474.      a query, the expected row structure must be specified in the

  475.      query itself, so that the system can know how to parse and plan

  476.      the query.  This syntax looks like:

  477.     </p><pre class="synopsis">

  478. <em class="replaceable"><code>function_call</code></em> [<span class="optional">AS</span>] <em class="replaceable"><code>alias</code></em> (<em class="replaceable"><code>column_definition</code></em> [<span class="optional">, ... </span>])

  479. <em class="replaceable"><code>function_call</code></em> AS [<span class="optional"><em class="replaceable"><code>alias</code></em></span>] (<em class="replaceable"><code>column_definition</code></em> [<span class="optional">, ... </span>])

  480. ROWS FROM( ... <em class="replaceable"><code>function_call</code></em> AS (<em class="replaceable"><code>column_definition</code></em> [<span class="optional">, ... </span>]) [<span class="optional">, ... </span>] )

  481. </pre><p>

  482.      When not using the <code class="literal">ROWS FROM()</code> syntax,

  483.      the <em class="replaceable"><code>column_definition</code></em> list replaces the column

  484.      alias list that could otherwise be attached to the <code class="literal">FROM</code>

  485.      item; the names in the column definitions serve as column aliases.

  486.      When using the <code class="literal">ROWS FROM()</code> syntax,

  487.      a <em class="replaceable"><code>column_definition</code></em> list can be attached to

  488.      each member function separately; or if there is only one member function

  489.      and no <code class="literal">WITH ORDINALITY</code> clause,

  490.      a <em class="replaceable"><code>column_definition</code></em> list can be written in

  491.      place of a column alias list following <code class="literal">ROWS FROM()</code>.

  492.     </p><p>

  493.      Consider this example:

  494. </p><pre class="programlisting">

  495. SELECT *

  496.     FROM dblink('dbname=mydb', 'SELECT proname, prosrc FROM pg_proc')

  497.       AS t1(proname name, prosrc text)

  498.     WHERE proname LIKE 'bytea%';

  499. </pre><p>

  500.      The <a class="xref" href="contrib-dblink-function.html" title="dblink"><span class="refentrytitle">dblink</span></a> function

  501.      (part of the <a class="xref" href="dblink.html" title="F.10. dblink">dblink</a> module) executes

  502.      a remote query.  It is declared to return

  503.      <code class="type">record</code> since it might be used for any kind of query.

  504.      The actual column set must be specified in the calling query so

  505.      that the parser knows, for example, what <code class="literal">*</code> should

  506.      expand to.

  507.     </p></div><div class="sect3" id="QUERIES-LATERAL"><div class="titlepage"><div><div><h4 class="title">7.2.1.5. <code class="literal">LATERAL</code> Subqueries</h4></div></div></div><a id="id-1.5.6.6.5.10.2" class="indexterm"></a><p>

  508.      Subqueries appearing in <code class="literal">FROM</code> can be

  509.      preceded by the key word <code class="literal">LATERAL</code>.  This allows them to

  510.      reference columns provided by preceding <code class="literal">FROM</code> items.

  511.      (Without <code class="literal">LATERAL</code>, each subquery is

  512.      evaluated independently and so cannot cross-reference any other

  513.      <code class="literal">FROM</code> item.)

  514.     </p><p>

  515.      Table functions appearing in <code class="literal">FROM</code> can also be

  516.      preceded by the key word <code class="literal">LATERAL</code>, but for functions the

  517.      key word is optional; the function's arguments can contain references

  518.      to columns provided by preceding <code class="literal">FROM</code> items in any case.

  519.     </p><p>

  520.      A <code class="literal">LATERAL</code> item can appear at top level in the

  521.      <code class="literal">FROM</code> list, or within a <code class="literal">JOIN</code> tree.  In the latter

  522.      case it can also refer to any items that are on the left-hand side of a

  523.      <code class="literal">JOIN</code> that it is on the right-hand side of.

  524.     </p><p>

  525.      When a <code class="literal">FROM</code> item contains <code class="literal">LATERAL</code>

  526.      cross-references, evaluation proceeds as follows: for each row of the

  527.      <code class="literal">FROM</code> item providing the cross-referenced column(s), or

  528.      set of rows of multiple <code class="literal">FROM</code> items providing the

  529.      columns, the <code class="literal">LATERAL</code> item is evaluated using that

  530.      row or row set's values of the columns.  The resulting row(s) are

  531.      joined as usual with the rows they were computed from.  This is

  532.      repeated for each row or set of rows from the column source table(s).

  533.     </p><p>

  534.      A trivial example of <code class="literal">LATERAL</code> is

  535. </p><pre class="programlisting">

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

  537. </pre><p>

  538.      This is not especially useful since it has exactly the same result as

  539.      the more conventional

  540. </p><pre class="programlisting">

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

  542. </pre><p>

  543.      <code class="literal">LATERAL</code> is primarily useful when the cross-referenced

  544.      column is necessary for computing the row(s) to be joined.  A common

  545.      application is providing an argument value for a set-returning function.

  546.      For example, supposing that <code class="function">vertices(polygon)</code> returns the

  547.      set of vertices of a polygon, we could identify close-together vertices

  548.      of polygons stored in a table with:

  549. </p><pre class="programlisting">

  550. SELECT p1.id, p2.id, v1, v2

  551. FROM polygons p1, polygons p2,

  552.      LATERAL vertices(p1.poly) v1,

  553.      LATERAL vertices(p2.poly) v2

  554. WHERE (v1 &lt;-&gt; v2) &lt; 10 AND p1.id != p2.id;

  555. </pre><p>

  556.      This query could also be written

  557. </p><pre class="programlisting">

  558. SELECT p1.id, p2.id, v1, v2

  559. FROM polygons p1 CROSS JOIN LATERAL vertices(p1.poly) v1,

  560.      polygons p2 CROSS JOIN LATERAL vertices(p2.poly) v2

  561. WHERE (v1 &lt;-&gt; v2) &lt; 10 AND p1.id != p2.id;

  562. </pre><p>

  563.      or in several other equivalent formulations.  (As already mentioned,

  564.      the <code class="literal">LATERAL</code> key word is unnecessary in this example, but

  565.      we use it for clarity.)

  566.     </p><p>

  567.      It is often particularly handy to <code class="literal">LEFT JOIN</code> to a

  568.      <code class="literal">LATERAL</code> subquery, so that source rows will appear in

  569.      the result even if the <code class="literal">LATERAL</code> subquery produces no

  570.      rows for them.  For example, if <code class="function">get_product_names()</code> returns

  571.      the names of products made by a manufacturer, but some manufacturers in

  572.      our table currently produce no products, we could find out which ones

  573.      those are like this:

  574. </p><pre class="programlisting">

  575. SELECT m.name

  576. FROM manufacturers m LEFT JOIN LATERAL get_product_names(m.id) pname ON true

  577. WHERE pname IS NULL;

  578. </pre><p>

  579.     </p></div></div><div class="sect2" id="QUERIES-WHERE"><div class="titlepage"><div><div><h3 class="title">7.2.2. The <code class="literal">WHERE</code> Clause</h3></div></div></div><a id="id-1.5.6.6.6.2" class="indexterm"></a><p>

  580.     The syntax of the <a class="xref" href="sql-select.html#SQL-WHERE" title="WHERE Clause"><code class="literal">WHERE</code> Clause</a> is

  581. </p><pre class="synopsis">

  582. WHERE <em class="replaceable"><code>search_condition</code></em>

  583. </pre><p>

  584.     where <em class="replaceable"><code>search_condition</code></em> is any value

  585.     expression (see <a class="xref" href="sql-expressions.html" title="4.2. Value Expressions">Section 4.2</a>) that

  586.     returns a value of type <code class="type">boolean</code>.

  587.    </p><p>

  588.     After the processing of the <code class="literal">FROM</code> clause is done, each

  589.     row of the derived virtual table is checked against the search

  590.     condition.  If the result of the condition is true, the row is

  591.     kept in the output table, otherwise (i.e., if the result is

  592.     false or null) it is discarded.  The search condition typically

  593.     references at least one column of the table generated in the

  594.     <code class="literal">FROM</code> clause; this is not required, but otherwise the

  595.     <code class="literal">WHERE</code> clause will be fairly useless.

  596.    </p><div class="note"><h3 class="title">Note</h3><p>

  597.      The join condition of an inner join can be written either in

  598.      the <code class="literal">WHERE</code> clause or in the <code class="literal">JOIN</code> clause.

  599.      For example, these table expressions are equivalent:

  600. </p><pre class="programlisting">

  601. FROM a, b WHERE a.id = b.id AND b.val &gt; 5

  602. </pre><p>

  603.      and:

  604. </p><pre class="programlisting">

  605. FROM a INNER JOIN b ON (a.id = b.id) WHERE b.val &gt; 5

  606. </pre><p>

  607.      or perhaps even:

  608. </p><pre class="programlisting">

  609. FROM a NATURAL JOIN b WHERE b.val &gt; 5

  610. </pre><p>

  611.      Which one of these you use is mainly a matter of style.  The

  612.      <code class="literal">JOIN</code> syntax in the <code class="literal">FROM</code> clause is

  613.      probably not as portable to other SQL database management systems,

  614.      even though it is in the SQL standard.  For

  615.      outer joins there is no choice:  they must be done in

  616.      the <code class="literal">FROM</code> clause.  The <code class="literal">ON</code> or <code class="literal">USING</code>

  617.      clause of an outer join is <span class="emphasis"><em>not</em></span> equivalent to a

  618.      <code class="literal">WHERE</code> condition, because it results in the addition

  619.      of rows (for unmatched input rows) as well as the removal of rows

  620.      in the final result.

  621.     </p></div><p>

  622.     Here are some examples of <code class="literal">WHERE</code> clauses:

  623. </p><pre class="programlisting">

  624. SELECT ... FROM fdt WHERE c1 &gt; 5

  625. 

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

  627. 

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

  629. 

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

  631. 

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

  633. 

  634. SELECT ... FROM fdt WHERE EXISTS (SELECT c1 FROM t2 WHERE c2 &gt; fdt.c1)

  635. </pre><p>

  636.     <code class="literal">fdt</code> is the table derived in the

  637.     <code class="literal">FROM</code> clause. Rows that do not meet the search

  638.     condition of the <code class="literal">WHERE</code> clause are eliminated from

  639.     <code class="literal">fdt</code>. Notice the use of scalar subqueries as

  640.     value expressions.  Just like any other query, the subqueries can

  641.     employ complex table expressions.  Notice also how

  642.     <code class="literal">fdt</code> is referenced in the subqueries.

  643.     Qualifying <code class="literal">c1</code> as <code class="literal">fdt.c1</code> is only necessary

  644.     if <code class="literal">c1</code> is also the name of a column in the derived

  645.     input table of the subquery.  But qualifying the column name adds

  646.     clarity even when it is not needed.  This example shows how the column

  647.     naming scope of an outer query extends into its inner queries.

  648.    </p></div><div class="sect2" id="QUERIES-GROUP"><div class="titlepage"><div><div><h3 class="title">7.2.3. The <code class="literal">GROUP BY</code> and <code class="literal">HAVING</code> Clauses</h3></div></div></div><a id="id-1.5.6.6.7.2" class="indexterm"></a><a id="id-1.5.6.6.7.3" class="indexterm"></a><p>

  649.     After passing the <code class="literal">WHERE</code> filter, the derived input

  650.     table might be subject to grouping, using the <code class="literal">GROUP BY</code>

  651.     clause, and elimination of group rows using the <code class="literal">HAVING</code>

  652.     clause.

  653.    </p><pre class="synopsis">

  654. SELECT <em class="replaceable"><code>select_list</code></em>

  655.     FROM ...

  656.     [<span class="optional">WHERE ...</span>]

  657.     GROUP BY <em class="replaceable"><code>grouping_column_reference</code></em> [<span class="optional">, <em class="replaceable"><code>grouping_column_reference</code></em></span>]...

  658. </pre><p>

  659.     The <a class="xref" href="sql-select.html#SQL-GROUPBY" title="GROUP BY Clause"><code class="literal">GROUP BY</code> Clause</a> is

  660.     used to group together those rows in a table that have the same

  661.     values in all the columns listed. The order in which the columns

  662.     are listed does not matter.  The effect is to combine each set

  663.     of rows having common values into one group row that

  664.     represents all rows in the group.  This is done to

  665.     eliminate redundancy in the output and/or compute aggregates that

  666.     apply to these groups.  For instance:

  667. </p><pre class="screen">

  668. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM test1;</code></strong>

  669.  x | y

  670. ---+---

  671.  a | 3

  672.  c | 2

  673.  b | 5

  674.  a | 1

  675. (4 rows)

  676. 

  677. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT x FROM test1 GROUP BY x;</code></strong>

  678.  x

  679. ---

  680.  a

  681.  b

  682.  c

  683. (3 rows)

  684. </pre><p>

  685.    </p><p>

  686.     In the second query, we could not have written <code class="literal">SELECT *

  687.     FROM test1 GROUP BY x</code>, because there is no single value

  688.     for the column <code class="literal">y</code> that could be associated with each

  689.     group.  The grouped-by columns can be referenced in the select list since

  690.     they have a single value in each group.

  691.    </p><p>

  692.     In general, if a table is grouped, columns that are not

  693.     listed in <code class="literal">GROUP BY</code> cannot be referenced except in aggregate

  694.     expressions.  An example with aggregate expressions is:

  695. </p><pre class="screen">

  696. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT x, sum(y) FROM test1 GROUP BY x;</code></strong>

  697.  x | sum

  698. ---+-----

  699.  a |   4

  700.  b |   5

  701.  c |   2

  702. (3 rows)

  703. </pre><p>

  704.     Here <code class="literal">sum</code> is an aggregate function that

  705.     computes a single value over the entire group.  More information

  706.     about the available aggregate functions can be found in <a class="xref" href="functions-aggregate.html" title="9.20. Aggregate Functions">Section 9.20</a>.

  707.    </p><div class="tip"><h3 class="title">Tip</h3><p>

  708.      Grouping without aggregate expressions effectively calculates the

  709.      set of distinct values in a column.  This can also be achieved

  710.      using the <code class="literal">DISTINCT</code> clause (see <a class="xref" href="queries-select-lists.html#QUERIES-DISTINCT" title="7.3.3. DISTINCT">Section 7.3.3</a>).

  711.     </p></div><p>

  712.     Here is another example:  it calculates the total sales for each

  713.     product (rather than the total sales of all products):

  714. </p><pre class="programlisting">

  715. SELECT product_id, p.name, (sum(s.units) * p.price) AS sales

  716.     FROM products p LEFT JOIN sales s USING (product_id)

  717.     GROUP BY product_id, p.name, p.price;

  718. </pre><p>

  719.     In this example, the columns <code class="literal">product_id</code>,

  720.     <code class="literal">p.name</code>, and <code class="literal">p.price</code> must be

  721.     in the <code class="literal">GROUP BY</code> clause since they are referenced in

  722.     the query select list (but see below).  The column

  723.     <code class="literal">s.units</code> does not have to be in the <code class="literal">GROUP

  724.     BY</code> list since it is only used in an aggregate expression

  725.     (<code class="literal">sum(...)</code>), which represents the sales

  726.     of a product.  For each product, the query returns a summary row about

  727.     all sales of the product.

  728.    </p><a id="id-1.5.6.6.7.11" class="indexterm"></a><p>

  729.     If the products table is set up so that, say,

  730.     <code class="literal">product_id</code> is the primary key, then it would be

  731.     enough to group by <code class="literal">product_id</code> in the above example,

  732.     since name and price would be <em class="firstterm">functionally

  733.     dependent</em> on the product ID, and so there would be no

  734.     ambiguity about which name and price value to return for each product

  735.     ID group.

  736.    </p><p>

  737.     In strict SQL, <code class="literal">GROUP BY</code> can only group by columns of

  738.     the source table but <span class="productname">PostgreSQL</span> extends

  739.     this to also allow <code class="literal">GROUP BY</code> to group by columns in the

  740.     select list.  Grouping by value expressions instead of simple

  741.     column names is also allowed.

  742.    </p><a id="id-1.5.6.6.7.14" class="indexterm"></a><p>

  743.     If a table has been grouped using <code class="literal">GROUP BY</code>,

  744.     but only certain groups are of interest, the

  745.     <code class="literal">HAVING</code> clause can be used, much like a

  746.     <code class="literal">WHERE</code> clause, to eliminate groups from the result.

  747.     The syntax is:

  748. </p><pre class="synopsis">

  749. SELECT <em class="replaceable"><code>select_list</code></em> FROM ... [<span class="optional">WHERE ...</span>] GROUP BY ... HAVING <em class="replaceable"><code>boolean_expression</code></em>

  750. </pre><p>

  751.     Expressions in the <code class="literal">HAVING</code> clause can refer both to

  752.     grouped expressions and to ungrouped expressions (which necessarily

  753.     involve an aggregate function).

  754.    </p><p>

  755.     Example:

  756. </p><pre class="screen">

  757. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT x, sum(y) FROM test1 GROUP BY x HAVING sum(y) &gt; 3;</code></strong>

  758.  x | sum

  759. ---+-----

  760.  a |   4

  761.  b |   5

  762. (2 rows)

  763. 

  764. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT x, sum(y) FROM test1 GROUP BY x HAVING x &lt; 'c';</code></strong>

  765.  x | sum

  766. ---+-----

  767.  a |   4

  768.  b |   5

  769. (2 rows)

  770. </pre><p>

  771.    </p><p>

  772.     Again, a more realistic example:

  773. </p><pre class="programlisting">

  774. SELECT product_id, p.name, (sum(s.units) * (p.price - p.cost)) AS profit

  775.     FROM products p LEFT JOIN sales s USING (product_id)

  776.     WHERE s.date &gt; CURRENT_DATE - INTERVAL '4 weeks'

  777.     GROUP BY product_id, p.name, p.price, p.cost

  778.     HAVING sum(p.price * s.units) &gt; 5000;

  779. </pre><p>

  780.     In the example above, the <code class="literal">WHERE</code> clause is selecting

  781.     rows by a column that is not grouped (the expression is only true for

  782.     sales during the last four weeks), while the <code class="literal">HAVING</code>

  783.     clause restricts the output to groups with total gross sales over

  784.     5000.  Note that the aggregate expressions do not necessarily need

  785.     to be the same in all parts of the query.

  786.    </p><p>

  787.     If a query contains aggregate function calls, but no <code class="literal">GROUP BY</code>

  788.     clause, grouping still occurs: the result is a single group row (or

  789.     perhaps no rows at all, if the single row is then eliminated by

  790.     <code class="literal">HAVING</code>).

  791.     The same is true if it contains a <code class="literal">HAVING</code> clause, even

  792.     without any aggregate function calls or <code class="literal">GROUP BY</code> clause.

  793.    </p></div><div class="sect2" id="QUERIES-GROUPING-SETS"><div class="titlepage"><div><div><h3 class="title">7.2.4. <code class="literal">GROUPING SETS</code>, <code class="literal">CUBE</code>, and <code class="literal">ROLLUP</code></h3></div></div></div><a id="id-1.5.6.6.8.2" class="indexterm"></a><a id="id-1.5.6.6.8.3" class="indexterm"></a><a id="id-1.5.6.6.8.4" class="indexterm"></a><p>

  794.     More complex grouping operations than those described above are possible

  795.     using the concept of <em class="firstterm">grouping sets</em>.  The data selected by

  796.     the <code class="literal">FROM</code> and <code class="literal">WHERE</code> clauses is grouped separately

  797.     by each specified grouping set, aggregates computed for each group just as

  798.     for simple <code class="literal">GROUP BY</code> clauses, and then the results returned.

  799.     For example:

  800. </p><pre class="screen">

  801. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT * FROM items_sold;</code></strong>

  802.  brand | size | sales

  803. -------+------+-------

  804.  Foo   | L    |  10

  805.  Foo   | M    |  20

  806.  Bar   | M    |  15

  807.  Bar   | L    |  5

  808. (4 rows)

  809. 

  810. <code class="prompt">=&gt;</code> <strong class="userinput"><code>SELECT brand, size, sum(sales) FROM items_sold GROUP BY GROUPING SETS ((brand), (size), ());</code></strong>

  811.  brand | size | sum

  812. -------+------+-----

  813.  Foo   |      |  30

  814.  Bar   |      |  20

  815.        | L    |  15

  816.        | M    |  35

  817.        |      |  50

  818. (5 rows)

  819. </pre><p>

  820.    </p><p>

  821.     Each sublist of <code class="literal">GROUPING SETS</code> may specify zero or more columns

  822.     or expressions and is interpreted the same way as though it were directly

  823.     in the <code class="literal">GROUP BY</code> clause.  An empty grouping set means that all

  824.     rows are aggregated down to a single group (which is output even if no

  825.     input rows were present), as described above for the case of aggregate

  826.     functions with no <code class="literal">GROUP BY</code> clause.

  827.    </p><p>

  828.     References to the grouping columns or expressions are replaced

  829.     by null values in result rows for grouping sets in which those

  830.     columns do not appear.  To distinguish which grouping a particular output

  831.     row resulted from, see <a class="xref" href="functions-aggregate.html#FUNCTIONS-GROUPING-TABLE" title="Table 9.59. Grouping Operations">Table 9.59</a>.

  832.    </p><p>

  833.     A shorthand notation is provided for specifying two common types of grouping set.

  834.     A clause of the form

  835. </p><pre class="programlisting">

  836. ROLLUP ( <em class="replaceable"><code>e1</code></em>, <em class="replaceable"><code>e2</code></em>, <em class="replaceable"><code>e3</code></em>, ... )

  837. </pre><p>

  838.     represents the given list of expressions and all prefixes of the list including

  839.     the empty list; thus it is equivalent to

  840. </p><pre class="programlisting">

  841. GROUPING SETS (

  842.     ( <em class="replaceable"><code>e1</code></em>, <em class="replaceable"><code>e2</code></em>, <em class="replaceable"><code>e3</code></em>, ... ),

  843.     ...

  844.     ( <em class="replaceable"><code>e1</code></em>, <em class="replaceable"><code>e2</code></em> ),

  845.     ( <em class="replaceable"><code>e1</code></em> ),

  846.     ( )

  847. )

  848. </pre><p>

  849.     This is commonly used for analysis over hierarchical data; e.g. total

  850.     salary by department, division, and company-wide total.

  851.    </p><p>

  852.     A clause of the form

  853. </p><pre class="programlisting">

  854. CUBE ( <em class="replaceable"><code>e1</code></em>, <em class="replaceable"><code>e2</code></em>, ... )

  855. </pre><p>

  856.     represents the given list and all of its possible subsets (i.e. the power

  857.     set).  Thus

  858. </p><pre class="programlisting">

  859. CUBE ( a, b, c )

  860. </pre><p>

  861.     is equivalent to

  862. </p><pre class="programlisting">

  863. GROUPING SETS (

  864.     ( a, b, c ),

  865.     ( a, b    ),

  866.     ( a,    c ),

  867.     ( a       ),

  868.     (    b, c ),

  869.     (    b    ),

  870.     (       c ),

  871.     (         )

  872. )

  873. </pre><p>

  874.    </p><p>

  875.     The individual elements of a <code class="literal">CUBE</code> or <code class="literal">ROLLUP</code>

  876.     clause may be either individual expressions, or sublists of elements in

  877.     parentheses.  In the latter case, the sublists are treated as single

  878.     units for the purposes of generating the individual grouping sets.

  879.     For example:

  880. </p><pre class="programlisting">

  881. CUBE ( (a, b), (c, d) )

  882. </pre><p>

  883.     is equivalent to

  884. </p><pre class="programlisting">

  885. GROUPING SETS (

  886.     ( a, b, c, d ),

  887.     ( a, b       ),

  888.     (       c, d ),

  889.     (            )

  890. )

  891. </pre><p>

  892.     and

  893. </p><pre class="programlisting">

  894. ROLLUP ( a, (b, c), d )

  895. </pre><p>

  896.     is equivalent to

  897. </p><pre class="programlisting">

  898. GROUPING SETS (

  899.     ( a, b, c, d ),

  900.     ( a, b, c    ),

  901.     ( a          ),

  902.     (            )

  903. )

  904. </pre><p>

  905.    </p><p>

  906.     The <code class="literal">CUBE</code> and <code class="literal">ROLLUP</code> constructs can be used either

  907.     directly in the <code class="literal">GROUP BY</code> clause, or nested inside a

  908.     <code class="literal">GROUPING SETS</code> clause.  If one <code class="literal">GROUPING SETS</code> clause

  909.     is nested inside another, the effect is the same as if all the elements of

  910.     the inner clause had been written directly in the outer clause.

  911.    </p><p>

  912.     If multiple grouping items are specified in a single <code class="literal">GROUP BY</code>

  913.     clause, then the final list of grouping sets is the cross product of the

  914.     individual items.  For example:

  915. </p><pre class="programlisting">

  916. GROUP BY a, CUBE (b, c), GROUPING SETS ((d), (e))

  917. </pre><p>

  918.     is equivalent to

  919. </p><pre class="programlisting">

  920. GROUP BY GROUPING SETS (

  921.     (a, b, c, d), (a, b, c, e),

  922.     (a, b, d),    (a, b, e),

  923.     (a, c, d),    (a, c, e),

  924.     (a, d),       (a, e)

  925. )

  926. </pre><p>

  927.    </p><div class="note"><h3 class="title">Note</h3><p>

  928.     The construct <code class="literal">(a, b)</code> is normally recognized in expressions as

  929.     a <a class="link" href="sql-expressions.html#SQL-SYNTAX-ROW-CONSTRUCTORS" title="4.2.13. Row Constructors">row constructor</a>.

  930.     Within the <code class="literal">GROUP BY</code> clause, this does not apply at the top

  931.     levels of expressions, and <code class="literal">(a, b)</code> is parsed as a list of

  932.     expressions as described above.  If for some reason you <span class="emphasis"><em>need</em></span>

  933.     a row constructor in a grouping expression, use <code class="literal">ROW(a, b)</code>.

  934.    </p></div></div><div class="sect2" id="QUERIES-WINDOW"><div class="titlepage"><div><div><h3 class="title">7.2.5. Window Function Processing</h3></div></div></div><a id="id-1.5.6.6.9.2" class="indexterm"></a><p>

  935.     If the query contains any window functions (see

  936.     <a class="xref" href="tutorial-window.html" title="3.5. Window Functions">Section 3.5</a>,

  937.     <a class="xref" href="functions-window.html" title="9.21. Window Functions">Section 9.21</a> and

  938.     <a class="xref" href="sql-expressions.html#SYNTAX-WINDOW-FUNCTIONS" title="4.2.8. Window Function Calls">Section 4.2.8</a>), these functions are evaluated

  939.     after any grouping, aggregation, and <code class="literal">HAVING</code> filtering is

  940.     performed.  That is, if the query uses any aggregates, <code class="literal">GROUP

  941.     BY</code>, or <code class="literal">HAVING</code>, then the rows seen by the window functions

  942.     are the group rows instead of the original table rows from

  943.     <code class="literal">FROM</code>/<code class="literal">WHERE</code>.

  944.    </p><p>

  945.     When multiple window functions are used, all the window functions having

  946.     syntactically equivalent <code class="literal">PARTITION BY</code> and <code class="literal">ORDER BY</code>

  947.     clauses in their window definitions are guaranteed to be evaluated in a

  948.     single pass over the data. Therefore they will see the same sort ordering,

  949.     even if the <code class="literal">ORDER BY</code> does not uniquely determine an ordering.

  950.     However, no guarantees are made about the evaluation of functions having

  951.     different <code class="literal">PARTITION BY</code> or <code class="literal">ORDER BY</code> specifications.

  952.     (In such cases a sort step is typically required between the passes of

  953.     window function evaluations, and the sort is not guaranteed to preserve

  954.     ordering of rows that its <code class="literal">ORDER BY</code> sees as equivalent.)

  955.    </p><p>

  956.     Currently, window functions always require presorted data, and so the

  957.     query output will be ordered according to one or another of the window

  958.     functions' <code class="literal">PARTITION BY</code>/<code class="literal">ORDER BY</code> clauses.

  959.     It is not recommended to rely on this, however.  Use an explicit

  960.     top-level <code class="literal">ORDER BY</code> clause if you want to be sure the

  961.     results are sorted in a particular way.

  962.    </p></div></div><div class="navfooter"><hr /><table width="100%" summary="Navigation footer"><tr><td width="40%" align="left"><a accesskey="p" href="queries-overview.html">Prev</a> </td><td width="20%" align="center"><a accesskey="u" href="queries.html">Up</a></td><td width="40%" align="right"> <a accesskey="n" href="queries-select-lists.html">Next</a></td></tr><tr><td width="40%" align="left" valign="top">7.1. Overview </td><td width="20%" align="center"><a accesskey="h" href="index.html">Home</a></td><td width="40%" align="right" valign="top"> 7.3. Select Lists</td></tr></table></div></body></html>
上海开阖软件有限公司 沪ICP备12045867号-1