sent in the older protocol always did.
  </para>

  <para>
   The ReadyForQuery ('<literal>Z</literal>') message includes a transaction status
   indicator.
  </para>

  <para>
   The distinction between BinaryRow and DataRow message types is gone; the
   single DataRow message type serves for returning data in all formats.
   Note that the layout of DataRow has changed to make it easier to parse.
   Also, the representation of binary values has changed: it is no longer
   directly tied to the server's internal representation.
  </para>

  <para>
   There is a new <quote>extended query</quote> sub-protocol, which adds the frontend
   message types Parse, Bind, Execute, Describe, Close, Flush, and Sync, and the
   backend message types ParseComplete, BindComplete, PortalSuspended,
   ParameterDescription, NoData, and CloseComplete.  Existing clients do not
   have to concern themselves with this sub-protocol, but making use of it
   might allow improvements in performance or functionality.
  </para>

  <para>
   <command>COPY</command> data is now encapsulated into CopyData and CopyDone messages.  There
   is a well-defined way to recover from errors during <command>COPY</command>.  The special
   <quote><literal>\.</literal></quote> last line is not needed anymore, and is not sent
   during <command>COPY OUT</command>.
   (It is still recognized as a terminator during text-mode <command>COPY
   IN</command>, but not in CSV mode.  The text-mode behavior is
   deprecated and may eventually be removed.)  Binary <command>COPY</command> is supported.
   The CopyInResponse and CopyOutResponse messages include fields indicating
   the number of columns and the format of each column.
  </para>

  <para>
   The layout of FunctionCall and FunctionCallResponse messages has changed.
   FunctionCall can now support passing NULL arguments to functions.  It also
   can handle passing parameters and retrieving results in either text or
   binary format.  There is no longer any reason to consider FunctionCall a
   potential security hole, since it does not offer direct access to internal
   server data representations.
  </para>

  <para>
   The backend sends ParameterStatus ('<literal>S</literal>') messages during connection
   startup for all parameters it considers interesting to the client library.
   Subsequently, a ParameterStatus message is sent whenever the active value
   changes for any of these parameters.
  </para>

  <para>
   The RowDescription ('<literal>T</literal>') message carries new table OID and column
   number fields for each column of the described row.  It also shows the format
   code for each column.
  </para>

  <para>
   The CursorResponse ('<literal>P</literal>') message is no longer generated by
   the backend.
  </para>

  <para>
   The NotificationResponse ('<literal>A</literal>') message has an additional string
   field, which can carry a <quote>payload</quote> string passed
   from the <command>NOTIFY</command> event sender.
  </para>

  <para>
   The EmptyQueryResponse ('<literal>I</literal>') message used to include an empty
   string parameter; this has been removed.
  </para>
 </sect1>
</chapter>