<command>COMMIT</command> if the preceding step(s)
    succeeded, or an implicit <command>ROLLBACK</command> if they failed.
    This implicit transaction block will only be detected by the server
    when the first command ends without a sync.  There are a few DDL
    commands (such as <command>CREATE DATABASE</command>) that cannot be
    executed inside a transaction block. If one of these is executed in a
    pipeline, it will fail unless it is the first command after a Sync.
    Furthermore, upon success it will force an immediate commit to preserve
    database consistency. Thus a Sync immediately following one of these
    commands has no effect except to respond with ReadyForQuery.
   </para>

   <para>
    When using this method, completion of the pipeline must be determined
    by counting ReadyForQuery messages and waiting for that to reach the
    number of Syncs sent.  Counting command completion responses is
    unreliable, since some of the commands may be skipped and thus not
    produce a completion message.
   </para>
  </sect2>

  <sect2 id="protocol-flow-function-call">
   <title>Function Call</title>

   <para>
    The Function Call sub-protocol allows the client to request a direct
    call of any function that exists in the database's
    <structname>pg_proc</structname> system catalog.  The client must have
    execute permission for the function.
   </para>

   <note>
    <para>
     The Function Call sub-protocol is a legacy feature that is probably best
     avoided in new code.  Similar results can be accomplished by setting up
     a prepared statement that does <literal>SELECT function($1, ...)</literal>.
     The Function Call cycle can then be replaced with Bind/Execute.
    </para>
   </note>

   <para>
    A Function Call cycle is initiated by the frontend sending a
    FunctionCall message to the backend.  The backend then sends one
    or more response messages depending on the results of the function
    call, and finally a ReadyForQuery response message.  ReadyForQuery
    informs the frontend that it can safely send a new query or
    function call.
   </para>

   <para>
    The possible response messages from the backend are:

    <variablelist>
     <varlistentry>
      <term>ErrorResponse</term>
      <listitem>
       <para>
        An error has occurred.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>FunctionCallResponse</term>
      <listitem>
       <para>
        The function call was completed and returned the result given
        in the message.
        (Note that the Function Call protocol can only handle a single
        scalar result, not a row type or set of results.)
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>ReadyForQuery</term>
      <listitem>
       <para>
        Processing of the function call is complete.  ReadyForQuery
        will always be sent, whether processing terminates
        successfully or with an error.
       </para>
      </listitem>
     </varlistentry>

     <varlistentry>
      <term>NoticeResponse</term>
      <listitem>
       <para>
        A warning message has been issued in relation to the function
        call.  Notices are in addition to other responses, i.e., the
        backend will continue processing the command.
       </para>
      </listitem>
     </varlistentry>
    </variablelist>
   </para>
  </sect2>

  <sect2 id="protocol-copy">
   <title>COPY Operations</title>

   <para>
    The <command>COPY</command> command allows high-speed bulk data transfer
    to or from the server.  Copy-in and copy-out operations each switch
    the connection into a distinct sub-protocol, which lasts until the
    operation is completed.
   </para>

   <para>
    Copy-in mode (data transfer to the server) is initiated when the
    backend executes a <command>COPY FROM STDIN</command> SQL statement.  The backend
    sends a CopyInResponse message to the frontend.  The frontend