window function is computed across the rows that fall into the
    same partition as the current row.
   </para>

   <para>
    You can also control the order in which rows are processed by
    window functions using <literal>ORDER BY</literal> within <literal>OVER</literal>.
    (The window <literal>ORDER BY</literal> does not even have to match the
    order in which the rows are output.)  Here is an example:

<programlisting>
SELECT depname, empno, salary,
       row_number() OVER (PARTITION BY depname ORDER BY salary DESC)
FROM empsalary;
</programlisting>

<screen>
  depname  | empno | salary | row_number
-----------+-------+--------+------------
 develop   |     8 |   6000 |          1
 develop   |    10 |   5200 |          2
 develop   |    11 |   5200 |          3
 develop   |     9 |   4500 |          4
 develop   |     7 |   4200 |          5
 personnel |     2 |   3900 |          1
 personnel |     5 |   3500 |          2
 sales     |     1 |   5000 |          1
 sales     |     4 |   4800 |          2
 sales     |     3 |   4800 |          3
(10 rows)
</screen>

    As shown here, the <function>row_number</function> window function
    assigns sequential numbers to the rows within each partition,
    in the order defined by the <literal>ORDER BY</literal> clause
    (with tied rows numbered in an unspecified order).
    <function>row_number</function> needs no explicit parameter,
    because its behavior
    is entirely determined by the <literal>OVER</literal> clause.
   </para>

   <para>
    The rows considered by a window function are those of the <quote>virtual
    table</quote> produced by the query's <literal>FROM</literal> clause as filtered by its
    <literal>WHERE</literal>, <literal>GROUP BY</literal>, and <literal>HAVING</literal> clauses
    if any.  For example, a row removed because it does not meet the
    <literal>WHERE</literal> condition is not seen by any window function.
    A query can contain multiple window functions that slice up the data
    in different ways using different <literal>OVER</literal> clauses, but
    they all act on the same collection of rows defined by this virtual table.
   </para>

   <para>
    We already saw that <literal>ORDER BY</literal> can be omitted if the ordering
    of rows is not important.  It is also possible to omit <literal>PARTITION
    BY</literal>, in which case there is a single partition containing all rows.
   </para>

   <para>
    There is another important concept associated with window functions:
    for each row, there is a set of rows within its partition called its
    <firstterm>window frame</firstterm>.  Some window functions act only
    on the rows of the window frame, rather than of the whole partition.
    By default, if <literal>ORDER BY</literal> is supplied then the frame consists of
    all rows from the start of the partition up through the current row, plus
    any following rows that are equal to the current row according to the
    <literal>ORDER BY</literal> clause.  When <literal>ORDER BY</literal> is omitted the
    default frame consists of all rows in the partition.
     <footnote>
      <para>
       There are options to define the window frame in other ways, but
       this tutorial does not cover them.  See
       <xref linkend="syntax-window-functions"/> for details.
      </para>
     </footnote>
    Here is an example using <function>sum</function>:
   </para>

<programlisting>
SELECT salary, sum(salary) OVER () FROM empsalary;
</programlisting>

<screen>
 salary |  sum
--------+-------
   5200 | 47100
   5000 | 47100
   3500 | 47100
   4800 | 47100
   3900 | 47100
   4200 | 47100
   4500 | 47100
   4800 | 47100
   6000 | 47100
   5200 | 47100
(10 rows)
</screen>

   <para>
    Above, since there is no <literal>ORDER BY</literal> in the <literal>OVER</literal>
    clause, the window frame is the same as the partition, which for lack of
    <literal>PARTITION BY</literal> is the whole table; in other words each sum is