the caller can continue using SPI facilities.
   If there is a failure during commit, the current transaction is instead
   rolled back and a new transaction is started, after which the error is
   thrown in the usual way.
  </para>

  <para>
   <function>SPI_commit_and_chain</function> is the same, but the new
   transaction is started with the same transaction
   characteristics as the just finished one, like with the SQL command
   <command>COMMIT AND CHAIN</command>.
  </para>

  <para>
   These functions can only be executed if the SPI connection has been set as
   nonatomic in the call to <function>SPI_connect_ext</function>.
  </para>
 </refsect1>
</refentry>

<!-- *********************************************** -->

<refentry id="spi-spi-rollback">
 <indexterm><primary>SPI_rollback</primary></indexterm>
 <indexterm><primary>SPI_rollback_and_chain</primary></indexterm>

 <refmeta>
  <refentrytitle>SPI_rollback</refentrytitle>
  <manvolnum>3</manvolnum>
 </refmeta>

 <refnamediv>
  <refname>SPI_rollback</refname>
  <refname>SPI_rollback_and_chain</refname>
  <refpurpose>abort the current transaction</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
<synopsis>
void SPI_rollback(void)
</synopsis>

<synopsis>
void SPI_rollback_and_chain(void)
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <function>SPI_rollback</function> rolls back the current transaction.  It
   is approximately equivalent to running the SQL
   command <command>ROLLBACK</command>.  After the transaction is rolled back,
   a new transaction is automatically started using default transaction
   characteristics, so that the caller can continue using SPI facilities.
  </para>
  <para>
   <function>SPI_rollback_and_chain</function> is the same, but the new
   transaction is started with the same transaction
   characteristics as the just finished one, like with the SQL command
   <command>ROLLBACK AND CHAIN</command>.
  </para>

  <para>
   These functions can only be executed if the SPI connection has been set as
   nonatomic in the call to <function>SPI_connect_ext</function>.
  </para>
 </refsect1>
</refentry>

<!-- *********************************************** -->

<refentry id="spi-spi-start-transaction">
 <indexterm><primary>SPI_start_transaction</primary></indexterm>

 <refmeta>
  <refentrytitle>SPI_start_transaction</refentrytitle>
  <manvolnum>3</manvolnum>
 </refmeta>

 <refnamediv>
  <refname>SPI_start_transaction</refname>
  <refpurpose>obsolete function</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
<synopsis>
void SPI_start_transaction(void)
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <function>SPI_start_transaction</function> does nothing, and exists
   only for code compatibility with
   earlier <productname>PostgreSQL</productname> releases.  It used to
   be required after calling <function>SPI_commit</function>
   or <function>SPI_rollback</function>, but now those functions start
   a new transaction automatically.
  </para>
 </refsect1>
</refentry>

 </sect1>

 <sect1 id="spi-visibility">
  <title>Visibility of Data Changes</title>

  <para>
   The following rules govern the visibility of data changes in
   functions that use SPI (or any other C function):

   <itemizedlist>
    <listitem>
     <para>
      During the execution of an SQL command, any data changes made by
      the command are invisible to the command itself.  For
      example, in:
<programlisting>
INSERT INTO a SELECT * FROM a;
</programlisting>
      the inserted rows are invisible to the <command>SELECT</command>
      part.
     </para>
    </listitem>

    <listitem>
     <para>
      Changes made by a command C are visible to all commands that are
      started after C, no matter whether they are started inside C
      (during the execution of C) or after C is done.
     </para>
    </listitem>

    <listitem>
     <para>
      Commands executed via SPI inside a function called by an SQL