select.sgml

PostgreSQL7.4.6 for Linux

      <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>