equivalent to
<synopsis>
(<replaceable>query1</replaceable> UNION <replaceable>query2</replaceable>) EXCEPT <replaceable>query3</replaceable>
</synopsis>
   As shown here, you can use parentheses to control the order of
   evaluation.  Without parentheses, <literal>UNION</literal>
   and <literal>EXCEPT</literal> associate left-to-right,
   but <literal>INTERSECT</literal> binds more tightly than those two
   operators.  Thus
<synopsis>
<replaceable>query1</replaceable> UNION <replaceable>query2</replaceable> INTERSECT <replaceable>query3</replaceable>
</synopsis>
   means
<synopsis>
<replaceable>query1</replaceable> UNION (<replaceable>query2</replaceable> INTERSECT <replaceable>query3</replaceable>)
</synopsis>
   You can also surround an individual <replaceable>query</replaceable>
   with parentheses.  This is important if
   the <replaceable>query</replaceable> needs to use any of the clauses
   discussed in following sections, such as <literal>LIMIT</literal>.
   Without parentheses, you'll get a syntax error, or else the clause will
   be understood as applying to the output of the set operation rather
   than one of its inputs.  For example,
<synopsis>
SELECT a FROM b UNION SELECT x FROM y LIMIT 10
</synopsis>
   is accepted, but it means
<synopsis>
(SELECT a FROM b UNION SELECT x FROM y) LIMIT 10
</synopsis>
   not
<synopsis>
SELECT a FROM b UNION (SELECT x FROM y LIMIT 10)
</synopsis>
  </para>
 </sect1>


 <sect1 id="queries-order">
  <title>Sorting Rows (<literal>ORDER BY</literal>)</title>

  <indexterm zone="queries-order">
   <primary>sorting</primary>
  </indexterm>

  <indexterm zone="queries-order">
   <primary>ORDER BY</primary>
  </indexterm>

  <para>
   After a query has produced an output table (after the select list
   has been processed) it can optionally be sorted.  If sorting is not
   chosen, the rows will be returned in an unspecified order.  The actual
   order in that case will depend on the scan and join plan types and
   the order on disk, but it must not be relied on.  A particular
   output ordering can only be guaranteed if the sort step is explicitly
   chosen.
  </para>

  <para>
   The <literal>ORDER BY</literal> clause specifies the sort order:
<synopsis>
SELECT <replaceable>select_list</replaceable>
    FROM <replaceable>table_expression</replaceable>
    ORDER BY <replaceable>sort_expression1</replaceable> <optional>ASC | DESC</optional> <optional>NULLS { FIRST | LAST }</optional>
             <optional>, <replaceable>sort_expression2</replaceable> <optional>ASC | DESC</optional> <optional>NULLS { FIRST | LAST }</optional> ...</optional>
</synopsis>
   The sort expression(s) can be any expression that would be valid in the
   query's select list.  An example is:
<programlisting>
SELECT a, b FROM table1 ORDER BY a + b, c;
</programlisting>
   When more than one expression is specified,
   the later values are used to sort rows that are equal according to the
   earlier values.  Each expression can be followed by an optional
   <literal>ASC</literal> or <literal>DESC</literal> keyword to set the sort direction to
   ascending or descending.  <literal>ASC</literal> order is the default.
   Ascending order puts smaller values first, where
   <quote>smaller</quote> is defined in terms of the
   <literal>&lt;</literal> operator.  Similarly, descending order is
   determined with the <literal>&gt;</literal> operator.
    <footnote>
     <para>
      Actually, <productname>PostgreSQL</productname> uses the <firstterm>default B-tree
      operator class</firstterm> for the expression's data type to determine the sort
      ordering for <literal>ASC</literal> and <literal>DESC</literal>.  Conventionally,
      data types will be set up so that the <literal>&lt;</literal> and
      <literal>&gt;</literal> operators correspond to this sort ordering,
      but a user-defined data type's designer could choose to do something
      different.
     </para>
    </footnote>
  </para>

  <para>
   The <literal>NULLS