linkend="libpq-PQconsumeInput"/>.
      </para>

      <para>
       In pipeline mode, <function>PQgetResult</function> will return normally
       unless an error occurs; for any subsequent query sent after the one
       that caused the error until (and excluding) the next synchronization point,
       a special result of type <literal>PGRES_PIPELINE_ABORTED</literal> will
       be returned, and a null pointer will be returned after it.
       When the pipeline synchronization point is reached, a result of type
       <literal>PGRES_PIPELINE_SYNC</literal> will be returned.
       The result of the next query after the synchronization point follows
       immediately (that is, no null pointer is returned after
       the synchronization point).
      </para>

      <note>
       <para>
        Even when <xref linkend="libpq-PQresultStatus"/> indicates a fatal
        error, <xref linkend="libpq-PQgetResult"/> should be called until it
        returns a null pointer, to allow <application>libpq</application> to
        process the error information completely.
       </para>
      </note>
     </listitem>
    </varlistentry>
   </variablelist>
  </para>

  <para>
   Using <xref linkend="libpq-PQsendQuery"/> and
   <xref linkend="libpq-PQgetResult"/> solves one of
   <xref linkend="libpq-PQexec"/>'s problems:  If a command string contains
   multiple <acronym>SQL</acronym> commands, the results of those commands
   can be obtained individually.  (This allows a simple form of overlapped
   processing, by the way: the client can be handling the results of one
   command while the server is still working on later queries in the same
   command string.)
  </para>

  <para>
   Another frequently-desired feature that can be obtained with
   <xref linkend="libpq-PQsendQuery"/> and <xref linkend="libpq-PQgetResult"/>
   is retrieving large query results a limited number of rows at a time.
   This is discussed
   in <xref linkend="libpq-single-row-mode"/>.
  </para>

  <para>
   By itself, calling <xref linkend="libpq-PQgetResult"/>
   will still cause the client to block until the server completes the
   next <acronym>SQL</acronym> command.  This can be avoided by proper
   use of two more functions:

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

     <listitem>
      <para>
       If input is available from the server, consume it.
<synopsis>
int PQconsumeInput(PGconn *conn);
</synopsis>
      </para>

      <para>
       <xref linkend="libpq-PQconsumeInput"/> normally returns 1 indicating
       <quote>no error</quote>, but returns 0 if there was some kind of
       trouble (in which case <xref linkend="libpq-PQerrorMessage"/> can be
       consulted).  Note that the result does not say whether any input
       data was actually collected. After calling
       <xref linkend="libpq-PQconsumeInput"/>, the application can check
       <xref linkend="libpq-PQisBusy"/> and/or
       <function>PQnotifies</function> to see if their state has changed.
      </para>

      <para>
       <xref linkend="libpq-PQconsumeInput"/> can be called even if the
       application is not prepared to deal with a result or notification
       just yet.  The function will read available data and save it in
       a buffer, thereby causing a <function>select()</function>
       read-ready indication to go away.  The application can thus use
       <xref linkend="libpq-PQconsumeInput"/> to clear the
       <function>select()</function> condition immediately, and then
       examine the results at leisure.
      </para>
     </listitem>
    </varlistentry>

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

     <listitem>
      <para>
       Returns 1 if a command is busy, that is,
       <xref linkend="libpq-PQgetResult"/> would block waiting