foo
    ORDER BY ascii;
EXEC SQL OPEN foo_bar;
EXEC SQL FETCH foo_bar INTO :FooBar, DooDad;
...
EXEC SQL CLOSE foo_bar;
EXEC SQL COMMIT;
</programlisting>
  </para>

  <para>
   For more details about declaring a cursor, see <xref
   linkend="ecpg-sql-declare"/>; for more details about fetching rows from a
   cursor, see <xref linkend="sql-fetch"/>.
  </para>

   <note>
    <para>
     The ECPG <command>DECLARE</command> command does not actually
     cause a statement to be sent to the PostgreSQL backend.  The
     cursor is opened in the backend (using the
     backend's <command>DECLARE</command> command) at the point when
     the <command>OPEN</command> command is executed.
    </para>
   </note>
  </sect2>

  <sect2 id="ecpg-transactions">
   <title>Managing Transactions</title>

  <para>
   In the default mode, statements are committed only when
   <command>EXEC SQL COMMIT</command> is issued. The embedded SQL
   interface also supports autocommit of transactions (similar to
   <application>psql</application>'s default behavior) via the <option>-t</option>
   command-line option to <command>ecpg</command> (see <xref
   linkend="app-ecpg"/>) or via the <literal>EXEC SQL SET AUTOCOMMIT TO
   ON</literal> statement. In autocommit mode, each command is
   automatically committed unless it is inside an explicit transaction
   block. This mode can be explicitly turned off using <literal>EXEC
   SQL SET AUTOCOMMIT TO OFF</literal>.
  </para>

   <para>
    The following transaction management commands are available:

    <variablelist>
     <varlistentry id="ecpg-transactions-exec-sql-commit">
      <term><literal>EXEC SQL COMMIT</literal></term>
      <listitem>
       <para>
        Commit an in-progress transaction.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-rollback">
      <term><literal>EXEC SQL ROLLBACK</literal></term>
      <listitem>
       <para>
        Roll back an in-progress transaction.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-prepare-transaction">
      <term><literal>EXEC SQL PREPARE TRANSACTION </literal><replaceable class="parameter">transaction_id</replaceable></term>
      <listitem>
       <para>
        Prepare the current transaction for two-phase commit.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-commit-prepared">
      <term><literal>EXEC SQL COMMIT PREPARED </literal><replaceable class="parameter">transaction_id</replaceable></term>
      <listitem>
       <para>
        Commit a transaction that is in prepared state.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-rollback-prepared">
      <term><literal>EXEC SQL ROLLBACK PREPARED </literal><replaceable class="parameter">transaction_id</replaceable></term>
      <listitem>
       <para>
        Roll back a transaction that is in prepared state.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-autocommit-on">
      <term><literal>EXEC SQL SET AUTOCOMMIT TO ON</literal></term>
      <listitem>
       <para>
        Enable autocommit mode.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry id="ecpg-transactions-exec-sql-autocommit-off">
      <term><literal>EXEC SQL SET AUTOCOMMIT TO OFF</literal></term>
      <listitem>
       <para>
        Disable autocommit mode.  This is the default.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect2>

  <sect2 id="ecpg-prepared">
   <title>Prepared Statements</title>

   <para>
    When the values to be passed to an SQL statement are not known at
    compile time, or the same statement is going to be used many
    times, then prepared statements can be useful.
   </para>

   <para>
    The statement is prepared using the
    command <literal>PREPARE</literal>.