plpy.SPIError as e:
    result = "error transferring funds: %s" % e.args
else:
    result = "funds transferred correctly"
plan = plpy.prepare("INSERT INTO operations (result) VALUES ($1)", ["text"])
plpy.execute(plan, [result])
$$ LANGUAGE plpython3u;
</programlisting>
    Note that the use of <literal>try</literal>/<literal>except</literal> is still
    required.  Otherwise the exception would propagate to the top of
    the Python stack and would cause the whole function to abort with
    a <productname>PostgreSQL</productname> error, so that the
    <literal>operations</literal> table would not have any row
    inserted into it.  The subtransaction context manager does not
    trap errors, it only assures that all database operations executed
    inside its scope will be atomically committed or rolled back.  A
    rollback of the subtransaction block occurs on any kind of
    exception exit, not only ones caused by errors originating from
    database access.  A regular Python exception raised inside an
    explicit subtransaction block would also cause the subtransaction
    to be rolled back.
   </para>
  </sect2>
 </sect1>

 <sect1 id="plpython-transactions">
  <title>Transaction Management</title>

  <para>
   In a procedure called from the top level or an anonymous code block
   (<command>DO</command> command) called from the top level it is possible to
   control transactions.  To commit the current transaction, call
   <literal>plpy.commit()</literal>.  To roll back the current transaction,
   call <literal>plpy.rollback()</literal>.  (Note that it is not possible to
   run the SQL commands <command>COMMIT</command> or
   <command>ROLLBACK</command> via <function>plpy.execute</function> or
   similar.  It has to be done using these functions.)  After a transaction is
   ended, a new transaction is automatically started, so there is no separate
   function for that.
  </para>

  <para>
   Here is an example:
<programlisting>
CREATE PROCEDURE transaction_test1()
LANGUAGE plpython3u
AS $$
for i in range(0, 10):
    plpy.execute("INSERT INTO test1 (a) VALUES (%d)" % i)
    if i % 2 == 0:
        plpy.commit()
    else:
        plpy.rollback()
$$;

CALL transaction_test1();
</programlisting>
  </para>

  <para>
   Transactions cannot be ended when an explicit subtransaction is active.
  </para>
 </sect1>

 <sect1 id="plpython-util">
  <title>Utility Functions</title>
  <para>
   The <literal>plpy</literal> module also provides the functions
   <simplelist>
    <member><literal>plpy.debug(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.log(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.info(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.notice(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.warning(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.error(<replaceable>msg, **kwargs</replaceable>)</literal></member>
    <member><literal>plpy.fatal(<replaceable>msg, **kwargs</replaceable>)</literal></member>
   </simplelist>
   <indexterm><primary>elog</primary><secondary>in PL/Python</secondary></indexterm>
   <function>plpy.error</function> and <function>plpy.fatal</function>
   actually raise a Python exception which, if uncaught, propagates out to
   the calling query, causing the current transaction or subtransaction to
   be aborted.  <literal>raise plpy.Error(<replaceable>msg</replaceable>)</literal> and
   <literal>raise plpy.Fatal(<replaceable>msg</replaceable>)</literal> are
   equivalent to calling <literal>plpy.error(<replaceable>msg</replaceable>)</literal> and
   <literal>plpy.fatal(<replaceable>msg</replaceable>)</literal>, respectively but
   the <literal>raise</literal> form does not allow passing keyword arguments.
   The other functions only generate messages of different priority levels.
   Whether messages of a particular