backend.  In the <quote>extended query</quote> protocol,
   processing of queries is separated into multiple steps: parsing,
   binding of parameter values, and execution.  This offers flexibility
   and performance benefits, at the cost of extra complexity.
  </para>

  <para>
   Normal operation has additional sub-protocols for special operations
   such as <command>COPY</command>.
  </para>

 <sect2 id="protocol-message-concepts">
  <title>Messaging Overview</title>

  <para>
   All communication is through a stream of messages.  The first byte of a
   message identifies the message type, and the next four bytes specify the
   length of the rest of the message (this length count includes itself, but
   not the message-type byte).  The remaining contents of the message are
   determined by the message type.  For historical reasons, the very first
   message sent by the client (the startup message) has no initial
   message-type byte.
  </para>

  <para>
   To avoid losing synchronization with the message stream, both servers and
   clients typically read an entire message into a buffer (using the byte
   count) before attempting to process its contents.  This allows easy
   recovery if an error is detected while processing the contents.  In
   extreme situations (such as not having enough memory to buffer the
   message), the receiver can use the byte count to determine how much
   input to skip before it resumes reading messages.
  </para>

  <para>
   Conversely, both servers and clients must take care never to send an
   incomplete message.  This is commonly done by marshaling the entire message
   in a buffer before beginning to send it.  If a communications failure
   occurs partway through sending or receiving a message, the only sensible
   response is to abandon the connection, since there is little hope of
   recovering message-boundary synchronization.
  </para>
 </sect2>

  <sect2 id="protocol-query-concepts">
   <title>Extended Query Overview</title>

   <para>
    In the extended-query protocol, execution of SQL commands is divided
    into multiple steps.  The state retained between steps is represented
    by two types of objects: <firstterm>prepared statements</firstterm> and
    <firstterm>portals</firstterm>.  A prepared statement represents the result of
    parsing and semantic analysis of a textual query string.
    A prepared statement is not in itself ready to execute, because it might
    lack specific values for <firstterm>parameters</firstterm>.  A portal represents
    a ready-to-execute or already-partially-executed statement, with any
    missing parameter values filled in.  (For <command>SELECT</command> statements,
    a portal is equivalent to an open cursor, but we choose to use a different
    term since cursors don't handle non-<command>SELECT</command> statements.)
   </para>

   <para>
    The overall execution cycle consists of a <firstterm>parse</firstterm> step,
    which creates a prepared statement from a textual query string; a
    <firstterm>bind</firstterm> step, which creates a portal given a prepared
    statement and values for any needed parameters; and an
    <firstterm>execute</firstterm> step that runs a portal's query.  In the case of
    a query that returns rows (<command>SELECT</command>, <command>SHOW</command>, etc.),
    the execute step can be told to fetch only
    a limited number of rows, so that multiple execute steps might be needed
    to complete the operation.
   </para>

   <para>
    The backend can keep track of multiple prepared statements and portals
    (but note that these exist only within a session, and are never shared
    across sessions).  Existing prepared statements and portals are
    referenced by names assigned when they were created.  In addition,
    an <quote>unnamed</quote> prepared statement and portal exist.  Although these
    behave largely the same as named objects, operations on them are optimized
    for the case of executing a query