the supplied parameter values substituted into it.
  </para>

  <para>
   For more information on query planning and the statistics collected
   by <productname>PostgreSQL</productname> for that purpose, see
   the <xref linkend="sql-analyze"/>
   documentation.
  </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 or their planner statistics have
   been updated 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.)  These rules make use of a
   prepared statement semantically almost equivalent to re-submitting the
   same query text over and over, but with a performance benefit if no object
   definitions are changed, especially if the best plan remains the same
   across uses.  An example of a case where the semantic equivalence is not
   perfect is that if the statement refers to a table by an unqualified name,
   and then a new table of the same name is created in a schema appearing
   earlier in the <varname>search_path</varname>, no automatic re-parse will occur
   since no object used in the statement changed.  However, if some other
   change forces a re-parse, the new table will be referenced in subsequent
   uses.
  </para>

  <para>
   You can see all prepared statements available in the session by querying the
   <link linkend="view-pg-prepared-statements"><structname>pg_prepared_statements</structname></link>
   system view.
  </para>
 </refsect1>

 <refsect1 id="sql-prepare-examples" xreflabel="Examples">
  <title>Examples</title>
  <para>
   Create a prepared statement for an <command>INSERT</command>
   statement, and then execute it:
<programlisting>
PREPARE fooplan (int, text, bool, numeric) AS
    INSERT INTO foo VALUES($1, $2, $3, $4);
EXECUTE fooplan(1, 'Hunter Valley', 't', 200.00);
</programlisting>
  </para>

  <para>
   Create a prepared statement for a <command>SELECT</command>
   statement, and then execute it:
<programlisting>
PREPARE usrrptplan (int) AS
    SELECT * FROM users u, logs l WHERE u.usrid=$1 AND u.usrid=l.usrid
    AND l.date = $2;
EXECUTE usrrptplan(1, current_date);
</programlisting>

   In this example, the data type of the second parameter is not specified,
   so it is inferred from the context in which <literal>$2</literal> is used.
  </para>
 </refsect1>
 <refsect1>
  <title>Compatibility</title>

  <para>
   The SQL standard includes a <command>PREPARE</command> statement,
   but it is only for use in embedded SQL. This version of the
   <command>PREPARE</command> statement also uses a somewhat different
   syntax.
  </para>
 </refsect1>

 <refsect1>
  <title>See Also</title>

  <simplelist type="inline">
   <member><xref linkend="sql-deallocate"/></member>
   <member><xref linkend="sql-execute"/></member>
  </simplelist>
 </refsect1>
</refentry>