<productname>PostgreSQL</productname> actually treats every SQL statement as being
    executed within a transaction.  If you do not issue a <command>BEGIN</command>
    command,
    then each individual statement has an implicit <command>BEGIN</command> and
    (if successful) <command>COMMIT</command> wrapped around it.  A group of
    statements surrounded by <command>BEGIN</command> and <command>COMMIT</command>
    is sometimes called a <firstterm>transaction block</firstterm>.
   </para>

   <note>
    <para>
     Some client libraries issue <command>BEGIN</command> and <command>COMMIT</command>
     commands automatically, so that you might get the effect of transaction
     blocks without asking.  Check the documentation for the interface
     you are using.
    </para>
   </note>

   <para>
    It's possible to control the statements in a transaction in a more
    granular fashion through the use of <firstterm>savepoints</firstterm>.  Savepoints
    allow you to selectively discard parts of the transaction, while
    committing the rest.  After defining a savepoint with
    <command>SAVEPOINT</command>, you can if needed roll back to the savepoint
    with <command>ROLLBACK TO</command>.  All the transaction's database changes
    between defining the savepoint and rolling back to it are discarded, but
    changes earlier than the savepoint are kept.
   </para>

   <para>
    After rolling back to a savepoint, it continues to be defined, so you can
    roll back to it several times.  Conversely, if you are sure you won't need
    to roll back to a particular savepoint again, it can be released, so the
    system can free some resources.  Keep in mind that either releasing or
    rolling back to a savepoint
    will automatically release all savepoints that were defined after it.
   </para>

   <para>
    All this is happening within the transaction block, so none of it
    is visible to other database sessions.  When and if you commit the
    transaction block, the committed actions become visible as a unit
    to other sessions, while the rolled-back actions never become visible
    at all.
   </para>

   <para>
    Remembering the bank database, suppose we debit $100.00 from Alice's
    account, and credit Bob's account, only to find later that we should
    have credited Wally's account.  We could do it using savepoints like
    this:

<programlisting>
BEGIN;
UPDATE accounts SET balance = balance - 100.00
    WHERE name = 'Alice';
SAVEPOINT my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Bob';
-- oops ... forget that and use Wally's account
ROLLBACK TO my_savepoint;
UPDATE accounts SET balance = balance + 100.00
    WHERE name = 'Wally';
COMMIT;
</programlisting>
   </para>

   <para>
    This example is, of course, oversimplified, but there's a lot of control
    possible in a transaction block through the use of savepoints.
    Moreover, <command>ROLLBACK TO</command> is the only way to regain control of a
    transaction block that was put in aborted state by the
    system due to an error, short of rolling it back completely and starting
    again.
   </para>

  </sect1>


  <sect1 id="tutorial-window">
   <title>Window Functions</title>

   <indexterm zone="tutorial-window">
    <primary>window function</primary>
   </indexterm>

   <para>
    A <firstterm>window function</firstterm> performs a calculation across a set of
    table rows that are somehow related to the current row.  This is comparable
    to the type of calculation that can be done with an aggregate function.
    However, window functions do not cause rows to become grouped into a single
    output row like non-window aggregate calls would.  Instead, the
    rows retain their separate identities.  Behind the scenes, the window
    function is able to access more than just the current row of the query
    result.
   </para>

   <para>
    Here is an example that shows how to compare each employee's salary
    with