Notice how the <literal>AS</literal> clause is used to relabel the
    output column.  (The <literal>AS</literal> clause is optional.)
   </para>

   <para>
    A query can be <quote>qualified</quote> by adding a <literal>WHERE</literal>
    clause that specifies which rows are wanted.  The <literal>WHERE</literal>
    clause contains a Boolean (truth value) expression, and only rows for
    which the Boolean expression is true are returned.  The usual
    Boolean operators (<literal>AND</literal>,
    <literal>OR</literal>, and <literal>NOT</literal>) are allowed in
    the qualification.  For example, the following
    retrieves the weather of San Francisco on rainy days:

<programlisting>
SELECT * FROM weather
    WHERE city = 'San Francisco' AND prcp &gt; 0.0;
</programlisting>
    Result:
<screen>
     city      | temp_lo | temp_hi | prcp |    date
---------------+---------+---------+------+------------
 San Francisco |      46 |      50 | 0.25 | 1994-11-27
(1 row)
</screen>
   </para>

   <para>
    <indexterm><primary>ORDER BY</primary></indexterm>

    You can request that the results of a query
    be returned in sorted order:

<programlisting>
SELECT * FROM weather
    ORDER BY city;
</programlisting>

<screen>
     city      | temp_lo | temp_hi | prcp |    date
---------------+---------+---------+------+------------
 Hayward       |      37 |      54 |      | 1994-11-29
 San Francisco |      43 |      57 |    0 | 1994-11-29
 San Francisco |      46 |      50 | 0.25 | 1994-11-27
</screen>

    In this example, the sort order isn't fully specified, and so you
    might get the San Francisco rows in either order.  But you'd always
    get the results shown above if you do:

<programlisting>
SELECT * FROM weather
    ORDER BY city, temp_lo;
</programlisting>
   </para>

   <para>
    <indexterm><primary>DISTINCT</primary></indexterm>
    <indexterm><primary>duplicate</primary></indexterm>

    You can request that duplicate rows be removed from the result of
    a query:

<programlisting>
SELECT DISTINCT city
    FROM weather;
</programlisting>

<screen>
     city
---------------
 Hayward
 San Francisco
(2 rows)
</screen>

    Here again, the result row ordering might vary.
    You can ensure consistent results by using <literal>DISTINCT</literal> and
    <literal>ORDER BY</literal> together:
     <footnote>
      <para>
       In some database systems, including older versions of
       <productname>PostgreSQL</productname>, the implementation of
       <literal>DISTINCT</literal> automatically orders the rows and
       so <literal>ORDER BY</literal> is unnecessary.  But this is not
       required by the SQL standard, and current
       <productname>PostgreSQL</productname> does not guarantee that
       <literal>DISTINCT</literal> causes the rows to be ordered.
      </para>
     </footnote>

<programlisting>
SELECT DISTINCT city
    FROM weather
    ORDER BY city;
</programlisting>
   </para>
  </sect1>


  <sect1 id="tutorial-join">
   <title>Joins Between Tables</title>

   <indexterm zone="tutorial-join">
    <primary>join</primary>
   </indexterm>

   <para>
    Thus far, our queries have only accessed one table at a time.
    Queries can access multiple tables at once, or access the same
    table in such a way that multiple rows of the table are being
    processed at the same time.  Queries that access multiple tables
    (or multiple instances of the same table) at one time are called
    <firstterm>join</firstterm> queries.  They combine rows from one table
    with rows from a second table, with an expression specifying which rows
    are to be paired.  For example, to return all the weather records together
    with the location of the associated city, the database needs to compare
    the <structfield>city</structfield>
    column of each row of the <structname>weather</structname> table with the
    <structfield>name</structfield> column of all rows in the <structname>cities</structname>
    table, and