<varlistentry>
          <term><parameter>resultFormat</parameter></term>
          <listitem>
           <para>
            Specify zero to obtain results in text format, or one to obtain
            results in binary format.  (There is not currently a provision
            to obtain different result columns in different formats,
            although that is possible in the underlying protocol.)
           </para>
          </listitem>
         </varlistentry>
        </variablelist>
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>

   <para>
    The primary advantage of <xref linkend="libpq-PQexecParams"/> over
    <xref linkend="libpq-PQexec"/> is that parameter values can be separated from the
    command string, thus avoiding the need for tedious and error-prone
    quoting and escaping.
   </para>

   <para>
    Unlike <xref linkend="libpq-PQexec"/>, <xref linkend="libpq-PQexecParams"/> allows at most
    one SQL command in the given string.  (There can be semicolons in it,
    but not more than one nonempty command.)  This is a limitation of the
    underlying protocol, but has some usefulness as an extra defense against
    SQL-injection attacks.
   </para>

   <tip>
    <para>
     Specifying parameter types via OIDs is tedious, particularly if you prefer
     not to hard-wire particular OID values into your program.  However, you can
     avoid doing so even in cases where the server by itself cannot determine the
     type of the parameter, or chooses a different type than you want.  In the
     SQL command text, attach an explicit cast to the parameter symbol to show what
     data type you will send.  For example:
<programlisting>
SELECT * FROM mytable WHERE x = $1::bigint;
</programlisting>
     This forces parameter <literal>$1</literal> to be treated as <type>bigint</type>, whereas
     by default it would be assigned the same type as <literal>x</literal>.  Forcing the
     parameter type decision, either this way or by specifying a numeric type OID,
     is strongly recommended when sending parameter values in binary format, because
     binary format has less redundancy than text format and so there is less chance
     that the server will detect a type mismatch mistake for you.
    </para>
   </tip>

   <para>
    <variablelist>
     <varlistentry id="libpq-PQprepare">
      <term><function>PQprepare</function><indexterm><primary>PQprepare</primary></indexterm></term>

      <listitem>
       <para>
        Submits a request to create a prepared statement with the
        given parameters, and waits for completion.
<synopsis>
PGresult *PQprepare(PGconn *conn,
                    const char *stmtName,
                    const char *query,
                    int nParams,
                    const Oid *paramTypes);
</synopsis>
       </para>

       <para>
        <xref linkend="libpq-PQprepare"/> creates a prepared statement for later
        execution with <xref linkend="libpq-PQexecPrepared"/>.  This feature allows
        commands to be executed repeatedly without being parsed and
        planned each time;  see <xref linkend="sql-prepare"/> for details.
       </para>

       <para>
        The function creates a prepared statement named
        <parameter>stmtName</parameter> from the <parameter>query</parameter> string, which
        must contain a single SQL command.  <parameter>stmtName</parameter> can be
        <literal>""</literal> to create an unnamed statement, in which case any
        pre-existing unnamed statement is automatically replaced; otherwise
        it is an error if the statement name is already defined in the
        current session.  If any parameters are used, they are referred
        to in the query as <literal>$1</literal>, <literal>$2</literal>, etc.
        <parameter>nParams</parameter> is the number of parameters for which types
        are pre-specified in the array <parameter>paramTypes[]</parameter>.  (The
        array pointer can