<parameter>options</parameter></literal></term>
    <listitem>
     <para>
      struct containing optional arguments
     </para>
    </listitem>
   </varlistentry>
  </variablelist>

  <para>
   Callers should always zero out the entire <parameter>options</parameter>
   struct, then fill whichever fields they want to set.  This ensures forward
   compatibility of code, since any fields that are added to the struct in
   future will be defined to behave backwards-compatibly if they are zero.
   The currently available <parameter>options</parameter> fields are:
  </para>

  <variablelist>
   <varlistentry>
    <term><literal>ParamListInfo <parameter>params</parameter></literal></term>
    <listitem>
     <para>
      data structure containing query parameter types and values; NULL if none
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>bool <parameter>read_only</parameter></literal></term>
    <listitem>
     <para><literal>true</literal> for read-only execution</para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>bool <parameter>allow_nonatomic</parameter></literal></term>
    <listitem>
     <para>
      <literal>true</literal> allows non-atomic execution of CALL and DO
      statements (but this field is ignored unless
      the <symbol>SPI_OPT_NONATOMIC</symbol> flag was passed
      to <function>SPI_connect_ext</function>)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>bool <parameter>must_return_tuples</parameter></literal></term>
    <listitem>
     <para>
      if <literal>true</literal>, raise error if the query is not of a kind
      that returns tuples (this does not forbid the case where it happens to
      return zero tuples)
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>uint64 <parameter>tcount</parameter></literal></term>
    <listitem>
     <para>
      maximum number of rows to return,
      or <literal>0</literal> for no limit
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>DestReceiver * <parameter>dest</parameter></literal></term>
    <listitem>
     <para>
      <literal>DestReceiver</literal> object that will receive any tuples
      emitted by the query; if NULL, result tuples are accumulated into
      a <varname>SPI_tuptable</varname> structure, as
      in <function>SPI_execute_plan</function>
     </para>
    </listitem>
   </varlistentry>

   <varlistentry>
    <term><literal>ResourceOwner <parameter>owner</parameter></literal></term>
    <listitem>
     <para>
      The resource owner that will hold a reference count on the plan while
      it is executed.  If NULL, CurrentResourceOwner is used.  Ignored for
      non-saved plans, as SPI does not acquire reference counts on those.
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

 <refsect1>
  <title>Return Value</title>

  <para>
   The return value is the same as for <function>SPI_execute_plan</function>.
  </para>

  <para>
   When <parameter>options-&gt;dest</parameter> is NULL,
   <varname>SPI_processed</varname> and
   <varname>SPI_tuptable</varname> are set as in
   <function>SPI_execute_plan</function>.
   When <parameter>options-&gt;dest</parameter> is not NULL,
   <varname>SPI_processed</varname> is set to zero and
   <varname>SPI_tuptable</varname> is set to NULL.  If a tuple count
   is required, the caller's <literal>DestReceiver</literal> object must
   calculate it.
  </para>
 </refsect1>
</refentry>

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

<refentry id="spi-spi-execute-plan-with-paramlist">
 <indexterm><primary>SPI_execute_plan_with_paramlist</primary></indexterm>

 <refmeta>
  <refentrytitle>SPI_execute_plan_with_paramlist</refentrytitle>
  <manvolnum>3</manvolnum>
 </refmeta>

 <refnamediv>
  <refname>SPI_execute_plan_with_paramlist</refname>
  <refpurpose>execute a statement prepared by <function>SPI_prepare</function></refpurpose>