<listitem>
     <para>
      pointer to an array containing the <acronym>OID</acronym>s of
      the data types of the parameters
     </para>
    </listitem>
   </varlistentry>
  </variablelist>
 </refsect1>

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

  <para>
   <function>SPI_prepare</function> returns a non-null pointer to an
   <type>SPIPlan</type>, which is an opaque struct representing a prepared
   statement.  On error, <symbol>NULL</symbol> will be returned,
   and <varname>SPI_result</varname> will be set to one of the same
   error codes used by <function>SPI_execute</function>, except that
   it is set to <symbol>SPI_ERROR_ARGUMENT</symbol> if
   <parameter>command</parameter> is <symbol>NULL</symbol>, or if
   <parameter>nargs</parameter> is less than 0, or if <parameter>nargs</parameter> is
   greater than 0 and <parameter>argtypes</parameter> is <symbol>NULL</symbol>.
  </para>
 </refsect1>

 <refsect1>
  <title>Notes</title>

  <para>
   If no parameters are defined, a generic plan will be created at the
   first use of <function>SPI_execute_plan</function>, and used for all
   subsequent executions as well.  If there are parameters, the first few uses
   of <function>SPI_execute_plan</function> will generate custom plans
   that are specific to the supplied parameter values.  After enough uses
   of the same prepared statement, <function>SPI_execute_plan</function> will
   build a generic plan, and if that is not too much more expensive than the
   custom plans, it will start using the generic plan instead of re-planning
   each time.  If this default behavior is unsuitable, you can alter it by
   passing the <literal>CURSOR_OPT_GENERIC_PLAN</literal> or
   <literal>CURSOR_OPT_CUSTOM_PLAN</literal> flag to
   <function>SPI_prepare_cursor</function>, to force use of generic or custom
   plans respectively.
  </para>

  <para>
   Although the main point of a prepared statement is to avoid repeated parse
   analysis and planning of the statement, <productname>PostgreSQL</productname> will
   force re-analysis and re-planning of the statement before using it
   whenever database objects used in the statement have undergone
   definitional (DDL) changes since the previous use of the prepared
   statement.  Also, if the value of <xref linkend="guc-search-path"/> changes
   from one use to the next, the statement will be re-parsed using the new
   <varname>search_path</varname>.  (This latter behavior is new as of
   <productname>PostgreSQL</productname> 9.3.)  See <xref
   linkend="sql-prepare"/> for more information about the behavior of prepared
   statements.
  </para>

  <para>
   This function should only be called from a connected C function.
  </para>

  <para>
   <type>SPIPlanPtr</type> is declared as a pointer to an opaque struct type in
   <filename>spi.h</filename>.  It is unwise to try to access its contents
   directly, as that makes your code much more likely to break in
   future revisions of <productname>PostgreSQL</productname>.
  </para>

  <para>
   The name <type>SPIPlanPtr</type> is somewhat historical, since the data
   structure no longer necessarily contains an execution plan.
  </para>
 </refsect1>
</refentry>

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

<refentry id="spi-spi-prepare-cursor">
 <indexterm><primary>SPI_prepare_cursor</primary></indexterm>

 <refmeta>
  <refentrytitle>SPI_prepare_cursor</refentrytitle>
  <manvolnum>3</manvolnum>
 </refmeta>

 <refnamediv>
  <refname>SPI_prepare_cursor</refname>
  <refpurpose>prepare a statement, without executing it yet</refpurpose>
 </refnamediv>

 <refsynopsisdiv>
<synopsis>
SPIPlanPtr SPI_prepare_cursor(const char * <parameter>command</parameter>, int <parameter>nargs</parameter>,
                              Oid * <parameter>argtypes</parameter>, int <parameter>cursorOptions</parameter>)
</synopsis>
 </refsynopsisdiv>

 <refsect1>
  <title>Description</title>

  <para>
   <function>SPI_prepare_cursor</function> is identical to