<para>
   This section provides a quick checklist of changes, for the benefit of
   developers trying to update existing client libraries to protocol 3.0.
  </para>

  <para>
   The initial startup packet uses a flexible list-of-strings format
   instead of a fixed format.  Notice that session default values for run-time
   parameters can now be specified directly in the startup packet.  (Actually,
   you could do that before using the <literal>options</literal> field, but given the
   limited width of <literal>options</literal> and the lack of any way to quote
   whitespace in the values, it wasn't a very safe technique.)
  </para>

  <para>
   All messages now have a length count immediately following the message type
   byte (except for startup packets, which have no type byte).  Also note that
   PasswordMessage now has a type byte.
  </para>

  <para>
   ErrorResponse and NoticeResponse ('<literal>E</literal>' and '<literal>N</literal>')
   messages now contain multiple fields, from which the client code can
   assemble an error message of the desired level of verbosity.  Note that
   individual fields will typically not end with a newline, whereas the single
   string 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.