a Sync message.  This parameterless message causes the
    backend to close the current transaction if it's not inside a
    <command>BEGIN</command>/<command>COMMIT</command> transaction block (<quote>close</quote>
    meaning to commit if no error, or roll back if error).  Then a
    ReadyForQuery response is issued.  The purpose of Sync is to provide
    a resynchronization point for error recovery.  When an error is detected
    while processing any extended-query message, the backend issues
    ErrorResponse, then reads and discards messages until a Sync is reached,
    then issues ReadyForQuery and returns to normal message processing.
    (But note that no skipping occurs if an error is detected
    <emphasis>while</emphasis> processing Sync &mdash; this ensures that there is one
    and only one ReadyForQuery sent for each Sync.)
   </para>

   <note>
    <para>
     Sync does not cause a transaction block opened with <command>BEGIN</command>
     to be closed.  It is possible to detect this situation since the
     ReadyForQuery message includes transaction status information.
    </para>
   </note>

   <para>
    In addition to these fundamental, required operations, there are several
    optional operations that can be used with extended-query protocol.
   </para>

   <para>
    The Describe message (portal variant) specifies the name of an existing
    portal (or an empty string for the unnamed portal).  The response is a
    RowDescription message describing the rows that will be returned by
    executing the portal; or a NoData message if the portal does not contain a
    query that will return rows; or ErrorResponse if there is no such portal.
   </para>

   <para>
    The Describe message (statement variant) specifies the name of an existing
    prepared statement (or an empty string for the unnamed prepared
    statement).  The response is a ParameterDescription message describing the
    parameters needed by the statement, followed by a RowDescription message
    describing the rows that will be returned when the statement is eventually
    executed (or a NoData message if the statement will not return rows).
    ErrorResponse is issued if there is no such prepared statement.  Note that
    since Bind has not yet been issued, the formats to be used for returned
    columns are not yet known to the backend; the format code fields in the
    RowDescription message will be zeroes in this case.
   </para>

   <tip>
    <para>
     In most scenarios the frontend should issue one or the other variant
     of Describe before issuing Execute, to ensure that it knows how to
     interpret the results it will get back.
    </para>
   </tip>

   <para>
    The Close message closes an existing prepared statement or portal
    and releases resources.  It is not an error to issue Close against
    a nonexistent statement or portal name.  The response is normally
    CloseComplete, but could be ErrorResponse if some difficulty is
    encountered while releasing resources.  Note that closing a prepared
    statement implicitly closes any open portals that were constructed
    from that statement.
   </para>

   <para>
    The Flush message does not cause any specific output to be generated,
    but forces the backend to deliver any data pending in its output
    buffers.  A Flush must be sent after any extended-query command except
    Sync, if the frontend wishes to examine the results of that command before
    issuing more commands.  Without Flush, messages returned by the backend
    will be combined into the minimum possible number of packets to minimize
    network overhead.
   </para>

   <note>
    <para>
     The simple Query message is approximately equivalent to the series Parse,
     Bind, portal Describe, Execute, Close, Sync, using the unnamed prepared
     statement and portal objects and no parameters.  One difference is that
     it will accept multiple SQL statements in the query string, automatically