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
    taken over the whole table and so we get the same result for each output
    row.  But if we add an <literal>ORDER BY</literal> clause, we get very different
    results:
   </para>

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

<screen>
 salary |  sum
--------+-------
   3500 |  3500
   3900 |  7400
   4200 | 11600
   4500 | 16100
   4800 | 25700
   4800 | 25700
   5000 | 30700
   5200 | 41100
   5200 | 41100
   6000 | 47100
(10 rows)
</screen>

   <para>
    Here the sum is taken from the first (lowest) salary up through the
    current one, including any duplicates of the current one (notice the
    results for the duplicated salaries).
   </para>

   <para>
    Window functions are permitted only in the <literal>SELECT</literal> list
    and the <literal>ORDER BY</literal> clause of the query. They are forbidden
    elsewhere, such as in <literal>GROUP BY</literal>, <literal>HAVING</literal>
    and <literal>WHERE</literal> clauses.  This is because they logically
    execute after the processing of those clauses.  Also, window functions
    execute after non-window aggregate functions.  This means it is valid to
    include an aggregate function call in the arguments of a window function,
    but not vice versa.
   </para>

   <para>
    If there is a need to filter or group rows after the window calculations
    are performed, you can use a sub-select.  For example:

<programlisting>
SELECT depname, empno, salary, enroll_date
FROM
  (SELECT depname, empno, salary, enroll_date,
     row_number() OVER (PARTITION BY depname ORDER BY salary DESC, empno) AS pos
     FROM empsalary
  ) AS ss
WHERE pos &lt; 3;
</programlisting>

    The above query only shows the rows from the inner query having
    <literal>row_number</literal> less than 3 (that is, the first
    two rows for each department).
   </para>

   <para>
    When a query involves multiple window functions, it is possible to write
    out each one with a separate <literal>OVER</literal> clause, but this is
    duplicative and error-prone if the same windowing behavior is wanted
    for several functions.  Instead, each windowing behavior can be named
    in a <literal>WINDOW</literal> clause and then referenced in <literal>OVER</literal>.
    For example:

<programlisting>
SELECT sum(salary) OVER w, avg(salary) OVER w
  FROM empsalary
  WINDOW w AS (PARTITION BY depname ORDER BY salary DESC);
</programlisting>
   </para>

   <para>
    More details about window functions can be found in
    <xref linkend="syntax-window-functions"/>,
    <xref linkend="functions-window"/>,
    <xref linkend="queries-window"/>, and the
    <xref linkend="sql-select"/> reference page.
   </para>
  </sect1>


  <sect1 id="tutorial-inheritance">
   <title>Inheritance</title>

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

   <para>
    Inheritance is a concept from object-oriented databases.  It opens