so no need for a <structname>PGconn</structname> parameter.
      </para>
     </listitem>
    </varlistentry>
   </variablelist>

  </sect2>

 </sect1>

 <sect1 id="libpq-async">
  <title>Asynchronous Command Processing</title>

  <indexterm zone="libpq-async">
   <primary>nonblocking connection</primary>
  </indexterm>

  <para>
   The <xref linkend="libpq-PQexec"/> function is adequate for submitting
   commands in normal, synchronous applications.  It has a few
   deficiencies, however, that can be of importance to some users:

   <itemizedlist>
    <listitem>
     <para>
      <xref linkend="libpq-PQexec"/> waits for the command to be completed.
      The application might have other work to do (such as maintaining a
      user interface), in which case it won't want to block waiting for
      the response.
     </para>
    </listitem>

    <listitem>
     <para>
      Since the execution of the client application is suspended while it
      waits for the result, it is hard for the application to decide that
      it would like to try to cancel the ongoing command.  (It can be done
      from a signal handler, but not otherwise.)
     </para>
    </listitem>

    <listitem>
     <para>
      <xref linkend="libpq-PQexec"/> can return only one
      <structname>PGresult</structname> structure.  If the submitted command
      string contains multiple <acronym>SQL</acronym> commands, all but
      the last <structname>PGresult</structname> are discarded by
      <xref linkend="libpq-PQexec"/>.
     </para>
    </listitem>

    <listitem>
     <para>
      <xref linkend="libpq-PQexec"/> always collects the command's entire result,
      buffering it in a single <structname>PGresult</structname>.  While
      this simplifies error-handling logic for the application, it can be
      impractical for results containing many rows.
     </para>
    </listitem>
   </itemizedlist>
  </para>

  <para>
   Applications that do not like these limitations can instead use the
   underlying functions that <xref linkend="libpq-PQexec"/> is built from:
   <xref linkend="libpq-PQsendQuery"/> and <xref linkend="libpq-PQgetResult"/>.
   There are also
   <xref linkend="libpq-PQsendQueryParams"/>,
   <xref linkend="libpq-PQsendPrepare"/>,
   <xref linkend="libpq-PQsendQueryPrepared"/>,
   <xref linkend="libpq-PQsendDescribePrepared"/>,
   <xref linkend="libpq-PQsendDescribePortal"/>,
   <xref linkend="libpq-PQsendClosePrepared"/>, and
   <xref linkend="libpq-PQsendClosePortal"/>,
   which can be used with <xref linkend="libpq-PQgetResult"/> to duplicate
   the functionality of
   <xref linkend="libpq-PQexecParams"/>,
   <xref linkend="libpq-PQprepare"/>,
   <xref linkend="libpq-PQexecPrepared"/>,
   <xref linkend="libpq-PQdescribePrepared"/>,
   <xref linkend="libpq-PQdescribePortal"/>,
   <xref linkend="libpq-PQclosePrepared"/>, and
   <xref linkend="libpq-PQclosePortal"/>
   respectively.

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

     <listitem>
      <para>
       Submits a command to the server without waiting for the result(s).
       1 is returned if the command was successfully dispatched and 0 if
       not (in which case, use <xref linkend="libpq-PQerrorMessage"/> to get more
       information about the failure).
<synopsis>
int PQsendQuery(PGconn *conn, const char *command);
</synopsis>

       After successfully calling <xref linkend="libpq-PQsendQuery"/>, call
       <xref linkend="libpq-PQgetResult"/> one or more times to obtain the
       results.  <xref linkend="libpq-PQsendQuery"/> cannot be called again
       (on the same connection) until <xref linkend="libpq-PQgetResult"/>
       has returned a null pointer, indicating that the command is done.
      </para>

      <para>
       In pipeline mode, this function is disallowed.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQsendQueryParams">