issued in relation to the query.
        Notices are in addition to other responses, i.e., the backend
        will continue processing the command.
       </para>
      </listitem>
     </varlistentry>

    </variablelist>
   </para>

   <para>
    The response to a <command>SELECT</command> query (or other queries that
    return row sets, such as <command>EXPLAIN</command> or <command>SHOW</command>)
    normally consists of RowDescription, zero or more
    DataRow messages, and then CommandComplete.
    <command>COPY</command> to or from the frontend invokes special protocol
    as described in <xref linkend="protocol-copy"/>.
    All other query types normally produce only
    a CommandComplete message.
   </para>

   <para>
    Since a query string could contain several queries (separated by
    semicolons), there might be several such response sequences before the
    backend finishes processing the query string.  ReadyForQuery is issued
    when the entire string has been processed and the backend is ready to
    accept a new query string.
   </para>

   <para>
    If a completely empty (no contents other than whitespace) query string
    is received, the response is EmptyQueryResponse followed by ReadyForQuery.
   </para>

   <para>
    In the event of an error, ErrorResponse is issued followed by
    ReadyForQuery.  All further processing of the query string is aborted by
    ErrorResponse (even if more queries remained in it).  Note that this
    might occur partway through the sequence of messages generated by an
    individual query.
   </para>

   <para>
    In simple Query mode, the format of retrieved values is always text,
    except when the given command is a <command>FETCH</command> from a cursor
    declared with the <literal>BINARY</literal> option.  In that case, the
    retrieved values are in binary format.  The format codes given in
    the RowDescription message tell which format is being used.
   </para>

   <para>
    A frontend must be prepared to accept ErrorResponse and
    NoticeResponse messages whenever it is expecting any other type of
    message.  See also <xref linkend="protocol-async"/> concerning messages
    that the backend might generate due to outside events.
   </para>

   <para>
    Recommended practice is to code frontends in a state-machine style
    that will accept any message type at any time that it could make sense,
    rather than wiring in assumptions about the exact sequence of messages.
   </para>

   <sect3 id="protocol-flow-multi-statement">
    <title>Multiple Statements in a Simple Query</title>

    <para>
     When a simple Query message contains more than one SQL statement
     (separated by semicolons), those statements are executed as a single
     transaction, unless explicit transaction control commands are included
     to force a different behavior.  For example, if the message contains
<programlisting>
INSERT INTO mytable VALUES(1);
SELECT 1/0;
INSERT INTO mytable VALUES(2);
</programlisting>
     then the divide-by-zero failure in the <command>SELECT</command> will force
     rollback of the first <command>INSERT</command>.  Furthermore, because
     execution of the message is abandoned at the first error, the second
     <command>INSERT</command> is never attempted at all.
    </para>

    <para>
     If instead the message contains
<programlisting>
BEGIN;
INSERT INTO mytable VALUES(1);
COMMIT;
INSERT INTO mytable VALUES(2);
SELECT 1/0;
</programlisting>
     then the first <command>INSERT</command> is committed by the
     explicit <command>COMMIT</command> command.  The second <command>INSERT</command>
     and the <command>SELECT</command> are still treated as a single transaction,
     so that the divide-by-zero failure will roll back the
     second <command>INSERT</command>, but not the first one.
    </para>

    <para>
     This behavior is implemented by running the statements in a
     multi-statement Query message in an <firstterm>implicit transaction