<listitem>       <para>        <literal>NATURAL</literal> is shorthand for a        <literal>USING</> list that mentions all columns in the two        tables that have the same names.       </para>      </listitem>     </varlistentry>    </variablelist>   </para>  </refsect2>     <refsect2 id="SQL-WHERE">   <title id="sql-where-title"><literal>WHERE</literal> Clause</title>   <para>    The optional <literal>WHERE</literal> clause has the general form<synopsis>WHERE <replaceable class="parameter">condition</replaceable></synopsis>    where <replaceable class="parameter">condition</replaceable> is    any expression that evaluates to a result of type    <type>boolean</type>.  Any row that does not satisfy this    condition will be eliminated from the output.  A row satisfies the    condition if it returns true when the actual row values are    substituted for any variable references.   </para>  </refsect2>    <refsect2 id="SQL-GROUPBY">   <title id="sql-groupby-title"><literal>GROUP BY</literal> Clause</title>   <para>    The optional <literal>GROUP BY</literal> clause has the general form<synopsis>GROUP BY <replaceable class="parameter">expression</replaceable> [, ...]</synopsis>   </para>   <para>    <literal>GROUP BY</literal> will condense into a single row all    selected rows that share the same values for the grouped    expressions.  <replaceable    class="parameter">expression</replaceable> can be an input column    name, or the name or ordinal number of an output column    (<command>SELECT</command> list item), or an arbitrary    expression formed from input-column values.  In case of ambiguity,    a <literal>GROUP BY</literal> name will be interpreted as an    input-column name rather than an output column name.   </para>   <para>    Aggregate functions, if any are used, are computed across all rows    making up each group, producing a separate value for each group    (whereas without <literal>GROUP BY</literal>, an aggregate    produces a single value computed across all the selected rows).    When <literal>GROUP BY</literal> is present, it is not valid for    the <command>SELECT</command> list expressions to refer to    ungrouped columns except within aggregate functions, since there    would be more than one possible value to return for an ungrouped    column.   </para>  </refsect2>  <refsect2 id="SQL-HAVING">   <title id="sql-having-title"><literal>HAVING</literal> Clause</title>   <para>    The optional <literal>HAVING</literal> clause has the general form<synopsis>HAVING <replaceable class="parameter">condition</replaceable></synopsis>    where <replaceable class="parameter">condition</replaceable> is    the same as specified for the <literal>WHERE</literal> clause.   </para>       <para>    <literal>HAVING</literal> eliminates group rows that do not    satisfy the condition.  <literal>HAVING</literal> is different    from <literal>WHERE</literal>: <literal>WHERE</literal> filters    individual rows before the application of <literal>GROUP    BY</literal>, while <literal>HAVING</literal> filters group rows    created by <literal>GROUP BY</literal>.  Each column referenced in    <replaceable class="parameter">condition</replaceable> must    unambiguously reference a grouping column, unless the reference    appears within an aggregate function.   </para>  </refsect2>    <refsect2 id="SQL-UNION">   <title id="sql-union-title"><literal>UNION</literal> Clause</title>   <para>    The <literal>UNION</literal> clause has this general form:<synopsis><replaceable class="parameter">select_statement</replaceable> UNION [ ALL ] <replaceable class="parameter">select_statement</replaceable></synopsis>    <replaceable class="parameter">select_statement</replaceable> is    any <command>SELECT</command> statement without an <literal>ORDER    BY</>, <literal>LIMIT</>, or <literal>FOR UPDATE</literal> clause.    (<literal>ORDER BY</> and <literal>LIMIT</> can be attached to a    subexpression if it is enclosed in parentheses.  Without    parentheses, these clauses will be taken to apply to the result of    the <literal>UNION</literal>, not to its right-hand input    expression.)   </para>       <para>    The <literal>UNION</literal> operator computes the set union of    the rows returned by the involved <command>SELECT</command>    statements.  A row is in the set union of two result sets if it    appears in at least one of the result sets.  The two    <command>SELECT</command> statements that represent the direct    operands of the <literal>UNION</literal> must produce the same    number of columns, and corresponding columns must be of compatible    data types.   </para>       <para>    The result of <literal>UNION</> does not contain any duplicate    rows unless the <literal>ALL</> option is specified.    <literal>ALL</> prevents elimination of duplicates.   </para>       <para>    Multiple <literal>UNION</> operators in the same    <command>SELECT</command> statement are evaluated left to right,    unless otherwise indicated by parentheses.   </para>       <para>    Currently, <literal>FOR UPDATE</> may not be specified either for    a <literal>UNION</> result or for any input of a <literal>UNION</>.   </para>  </refsect2>  <refsect2 id="SQL-INTERSECT">   <title id="sql-intersect-title"><literal>INTERSECT</literal> Clause</title>   <para>    The <literal>INTERSECT</literal> clause has this general form:<synopsis><replaceable class="parameter">select_statement</replaceable> INTERSECT [ ALL ] <replaceable class="parameter">select_statement</replaceable></synopsis>    <replaceable class="parameter">select_statement</replaceable> is    any <command>SELECT</command> statement without an <literal>ORDER    BY</>, <literal>LIMIT</>, or <literal>FOR UPDATE</literal> clause.   </para>   <para>    The <literal>INTERSECT</literal> operator computes the set    intersection of the rows returned by the involved    <command>SELECT</command> statements.  A row is in the    intersection of two result sets if it appears in both result sets.   </para>       <para>    The result of <literal>INTERSECT</literal> does not contain any    duplicate rows unless the <literal>ALL</> option is specified.    With <literal>ALL</>, a row that has m duplicates in the left    table and n duplicates in the right table will appear min(m,n)    times in the result set.   </para>       <para>    Multiple <literal>INTERSECT</literal> operators in the same    <command>SELECT</command> statement are evaluated left to right,    unless parentheses dictate otherwise.    <literal>INTERSECT</literal> binds more tightly than    <literal>UNION</literal>.  That is, <literal>A UNION B INTERSECT    C</literal> will be read as <literal>A UNION (B INTERSECT    C)</literal>.   </para>  </refsect2>  <refsect2 id="SQL-EXCEPT">   <title id="sql-except-title"><literal>EXCEPT</literal> Clause</title>   <para>    The <literal>EXCEPT</literal> clause has this general form:<synopsis><replaceable class="parameter">select_statement</replaceable> EXCEPT [ ALL ] <replaceable class="parameter">select_statement</replaceable></synopsis>    <replaceable class="parameter">select_statement</replaceable> is    any <command>SELECT</command> statement without an <literal>ORDER    BY</>, <literal>LIMIT</>, or <literal>FOR UPDATE</literal> clause.   </para>   <para>    The <literal>EXCEPT</literal> operator computes the set of rows    that are in the result of the left <command>SELECT</command>    statement but not in the result of the right one.   </para>       <para>    The result of <literal>EXCEPT</literal> does not contain any    duplicate rows unless the <literal>ALL</> option is specified.    With <literal>ALL</>, a row that has m duplicates in the left    table and n duplicates in the right table will appear max(m-n,0)    times in the result set.   </para>       <para>    Multiple <literal>EXCEPT</literal> operators in the same    <command>SELECT</command> statement are evaluated left to right,    unless parentheses dictate otherwise.  <literal>EXCEPT</> binds at    the same level as <literal>UNION</>.   </para>  </refsect2>  <refsect2 id="sql-select-list">   <title id="sql-select-list-title"><command>SELECT</command> List</title>   <para>    The <command>SELECT</command> list (between the key words    <literal>SELECT</> and <literal>FROM</>) specifies expressions    that form the output rows of the <command>SELECT</command>    statement.  The expressions can (and usually do) refer to columns    computed in the <literal>FROM</> clause.  Using the clause    <literal>AS <replaceable    class="parameter">output_name</replaceable></literal>, another    name can be specified for an output column.  This name is    primarily used to label the column for display.  It can also be    used to refer to the column's value in <literal>ORDER BY</> and    <literal>GROUP BY</> clauses, but not in the <literal>WHERE</> or    <literal>HAVING</> clauses; there you must write out the    expression instead.   </para>   <para>    Instead of an expression, <literal>*</literal> can be written in    the output list as a shorthand for all the columns of the selected    rows.  Also, one can write <literal><replaceable    class="parameter">table_name</replaceable>.*</literal> as a    shorthand for the columns coming from just that table.   </para>  </refsect2>  <refsect2 id="SQL-ORDERBY">   <title id="sql-orderby-title"><literal>ORDER BY</literal> Clause</title>   <para>    The optional <literal>ORDER BY</literal> clause has this general form:<synopsis>ORDER BY <replaceable class="parameter">expression</replaceable> [ ASC | DESC | USING <replaceable class="parameter">operator</replaceable> ] [, ...]</synopsis>    <replaceable class="parameter">expression</replaceable> can be the    name or ordinal number of an output column    (<command>SELECT</command> list item), or it can be an arbitrary    expression formed from input-column values.   </para>   <para>    The <literal>ORDER BY</literal> clause causes the result rows to    be sorted according to the specified expressions.  If two rows are    equal according to the leftmost expression, the are compared    according to the next expression and so on.  If they are equal    according to all specified expressions, they are returned in    an implementation-dependent order.   </para>   <para>    The ordinal number refers to the ordinal (left-to-right) position    of the result column. This feature makes it possible to define an    ordering on the basis of a column that does not have a unique    name.  This is never absolutely necessary because it is always    possible to assign a name to a result column using the    <literal>AS</> clause.   </para>       <para>    It is also possible to use arbitrary expressions in the    <literal>ORDER BY</literal> clause, including columns that do not    appear in the <command>SELECT</command> result list.  Thus the    following statement is valid:<programlisting>SELECT name FROM distributors ORDER BY code;</programlisting>    A limitation of this feature is that an <literal>ORDER BY</>    clause applying to the result of a <literal>UNION</>,    <literal>INTERSECT</>, or <literal>EXCEPT</> clause may only    specify an output column name or number, not an expression.   </para>       <para>    If an <literal>ORDER BY</> expression is a simple name that    matches both a result column name and an input column name,    <literal>ORDER BY</> will interpret it as the result column name.    This is the opposite of the choice that <literal>GROUP BY</> will    make in the same situation.  This inconsistency is made to be    compatible with the SQL standard.   </para>       <para>    Optionally one may add the key word <literal>ASC</> (ascending) or    <literal>DESC</> (descending) after any expression in the    <literal>ORDER BY</> clause.  If not specified, <literal>ASC</> is    assumed by default.  Alternatively, a specific ordering operator    name may be specified in the <literal>USING</> clause.    <literal>ASC</> is usually equivalent to <literal>USING &lt;</> and    <literal>DESC</> is usually equivalent to <literal>USING &gt;</>.    (But the creator of a user-defined data type can define exactly what the    default sort ordering is, and it might correspond to operators with other    names.)   </para>   <para>    The null value sorts higher than any other value. In other words,    with ascending sort order, null values sort at the end, and with    descending sort order, null values sort at the beginning.   </para>   <para>    Character-string data is sorted according to the locale-specific    collation order that was established when the database cluster    was initialized.   </para>  </refsect2>    <refsect2 id="SQL-LIMIT">   <title id="sql-limit-title"><literal>LIMIT</literal> Clause</title>   <para>    The <literal>LIMIT</literal> clause consists of two independent    sub-clauses:<synopsis>LIMIT { <replaceable class="parameter">count</replaceable> | ALL }OFFSET <replaceable class="parameter">start</replaceable></synopsis>    <replaceable class="parameter">count</replaceable> specifies the    maximum number of rows to return, while <replaceable    class="parameter">start</replaceable> specifies the number of rows    to skip before starting to return rows.  When both are specified,    <replaceable class="parameter">start</replaceable> rows are skipped    before starting to count the <replaceable    class="parameter">count</replaceable> rows to be returned.   </para>   <para>    When using <literal>LIMIT</>, it is a good idea to use an    <literal>ORDER BY</> clause that constrains the result rows into a    unique order.  Otherwise you will get an unpredictable subset of    the query's rows---you may be asking for the tenth through    twentieth rows, but tenth through twentieth in what ordering?  You    don't know what ordering unless you specify <literal>ORDER BY</>.   </para>   <para>    The query planner takes <literal>LIMIT</> into account when    generating a query plan, so you are very likely to get different    plans (yielding different row orders) depending on what you use    for <literal>LIMIT</> and <literal>OFFSET</>.  Thus, using    different <literal>LIMIT</>/<literal>OFFSET</> values to select    different subsets of a query result <emphasis>will give    inconsistent results</emphasis> unless you enforce a predictable    result ordering with <literal>ORDER BY</>.  This is not a bug; it    is an inherent consequence of the fact that SQL does not promise    to deliver the results of a query in any particular order unless    <literal>ORDER BY</> is used to constrain the order.   </para>  </refsect2>  <refsect2 id="sql-distinct">   <title id="sql-distinct-title"><literal>DISTINCT</literal> Clause</title>   <para>