transaction and does not execute any subsequent command in the queue
     until the next synchronization point;
     a <literal>PGRES_PIPELINE_ABORTED</literal> result is produced for
     each such command.
     (This remains true even if the commands in the pipeline would rollback
     the transaction.)
     Query processing resumes after the synchronization point.
    </para>

    <para>
     It's fine for one operation to depend on the results of a
     prior one; for example, one query may define a table that the next
     query in the same pipeline uses. Similarly, an application may
     create a named prepared statement and execute it with later
     statements in the same pipeline.
    </para>
   </sect3>

   <sect3 id="libpq-pipeline-results">
    <title>Processing Results</title>

    <para>
     To process the result of one query in a pipeline, the application calls
     <function>PQgetResult</function> repeatedly and handles each result
     until <function>PQgetResult</function> returns null.
     The result from the next query in the pipeline may then be retrieved using
     <function>PQgetResult</function> again and the cycle repeated.
     The application handles individual statement results as normal.
     When the results of all the queries in the pipeline have been
     returned, <function>PQgetResult</function> returns a result
     containing the status value <literal>PGRES_PIPELINE_SYNC</literal>
    </para>

    <para>
     The client may choose to defer result processing until the complete
     pipeline has been sent, or interleave that with sending further
     queries in the pipeline; see <xref linkend="libpq-pipeline-interleave"/>.
    </para>

    <para>
     <function>PQgetResult</function> behaves the same as for normal
     asynchronous processing except that it may contain the new
     <type>PGresult</type> types <literal>PGRES_PIPELINE_SYNC</literal>
     and <literal>PGRES_PIPELINE_ABORTED</literal>.
     <literal>PGRES_PIPELINE_SYNC</literal> is reported exactly once for each
     <function>PQpipelineSync</function> or
     <function>PQsendPipelineSync</function> at the corresponding point
     in the pipeline.
     <literal>PGRES_PIPELINE_ABORTED</literal> is emitted in place of a normal
     query result for the first error and all subsequent results
     until the next <literal>PGRES_PIPELINE_SYNC</literal>;
     see <xref linkend="libpq-pipeline-errors"/>.
    </para>

    <para>
     <function>PQisBusy</function>, <function>PQconsumeInput</function>, etc
     operate as normal when processing pipeline results.  In particular,
     a call to <function>PQisBusy</function> in the middle of a pipeline
     returns 0 if the results for all the queries issued so far have been
     consumed.
    </para>

    <para>
     <application>libpq</application> does not provide any information to the
     application about the query currently being processed (except that
     <function>PQgetResult</function> returns null to indicate that we start
     returning the results of next query). The application must keep track
     of the order in which it sent queries, to associate them with their
     corresponding results.
     Applications will typically use a state machine or a FIFO queue for this.
    </para>

   </sect3>

   <sect3 id="libpq-pipeline-errors">
    <title>Error Handling</title>

    <para>
     From the client's perspective, after <function>PQresultStatus</function>
     returns <literal>PGRES_FATAL_ERROR</literal>,
     the pipeline is flagged as aborted.
     <function>PQresultStatus</function> will report a
     <literal>PGRES_PIPELINE_ABORTED</literal> result for each remaining queued
     operation in an aborted pipeline. The result for
     <function>PQpipelineSync</function> or
     <function>PQsendPipelineSync</function> is reported as
     <literal>PGRES_PIPELINE_SYNC</literal> to signal the end of the aborted pipeline
     and resumption of normal result processing.
    </para>