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 should
    then send zero or more CopyData messages, forming a stream of input
    data.  (The message boundaries are not required to have anything to do
    with row boundaries, although that is often a reasonable choice.)
    The frontend can terminate the copy-in mode by sending either a CopyDone
    message (allowing successful termination) or a CopyFail message (which
    will cause the <command>COPY</command> SQL statement to fail with an
    error).  The backend then reverts to the command-processing mode it was
    in before the <command>COPY</command> started, which will be either simple or
    extended query protocol.  It will next send either CommandComplete
    (if successful) or ErrorResponse (if not).
   </para>

   <para>
    In the event of a backend-detected error during copy-in mode (including
    receipt of a CopyFail message), the backend will issue an ErrorResponse
    message.  If the <command>COPY</command> command was issued via an extended-query
    message, the backend will now discard frontend messages until a Sync
    message is received, then it will issue ReadyForQuery and return to normal
    processing.  If the <command>COPY</command> command was issued in a simple
    Query message, the rest of that message is discarded and ReadyForQuery
    is issued.  In either case, any subsequent CopyData, CopyDone, or CopyFail
    messages issued by the frontend will simply be dropped.
   </para>

   <para>
    The backend will ignore Flush and Sync messages received during copy-in
    mode.  Receipt of any other non-copy message type constitutes an error
    that will abort the copy-in state as described above.  (The exception for
    Flush and Sync is for the convenience of client libraries that always
    send Flush or Sync after an Execute message, without checking whether
    the command to be executed is a <command>COPY FROM STDIN</command>.)
   </para>

   <para>
    Copy-out mode (data transfer from the server) is initiated when the
    backend executes a <command>COPY TO STDOUT</command> SQL statement.  The backend
    sends a CopyOutResponse message to the frontend, followed by
    zero or more CopyData messages (always one per row), followed by CopyDone.
    The backend then reverts to the command-processing mode it was
    in before the <command>COPY</command> started, and sends CommandComplete.
    The frontend cannot abort the transfer (except by closing the connection
    or issuing a Cancel request),
    but it can discard unwanted CopyData and CopyDone messages.
   </para>

   <para>
    In the event of a backend-detected error during copy-out mode,
    the backend will issue an ErrorResponse message and revert to normal
    processing.  The frontend should treat receipt of ErrorResponse as
    terminating the copy-out mode.
   </para>

   <para>
    It is possible for NoticeResponse and ParameterStatus messages to be
    interspersed between CopyData messages; frontends must handle these cases,
    and should