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 only once and then discarding it,
    whereas operations on named objects are optimized on the expectation
    of multiple uses.
   </para>
  </sect2>

  <sect2 id="protocol-format-codes">
   <title>Formats and Format Codes</title>

   <para>
    Data of a particular data type might be transmitted in any of several
    different <firstterm>formats</firstterm>.  As of <productname>PostgreSQL</productname> 7.4
    the only supported formats are <quote>text</quote> and <quote>binary</quote>,
    but the protocol makes provision for future extensions.  The desired
    format for any value is specified by a <firstterm>format code</firstterm>.
    Clients can specify a format code for each transmitted parameter value
    and for each column of a query result.  Text has format code zero,
    binary has format code one, and all other format codes are reserved
    for future definition.
   </para>

   <para>
    The text representation of values is whatever strings are produced
    and accepted by the input/output conversion functions for the
    particular data type.  In the transmitted representation, there is
    no trailing null character; the frontend must add one to received
    values if it wants to process them as C strings.
    (The text format does not allow embedded nulls, by the way.)
   </para>

   <para>
    Binary representations for integers use network byte order (most
    significant byte first).  For other data types consult the documentation
    or source code to learn about the binary representation.  Keep in mind
    that binary representations for complex data types might change across
    server versions; the text format is usually the more portable choice.
   </para>
  </sect2>

  <sect2 id="protocol-versions">
   <title>Protocol versions</title>

   <para>
    The current, latest version of the protocol is version 3.2. However, for
    backwards compatibility with old server versions and middleware that don't
    support the version negotiation yet, libpq still uses protocol version 3.0
    by default.
   </para>

   <para>
    A single server can support multiple protocol versions.  The initial
    startup-request message tells the server which protocol version the client
    is attempting to use.  If the major version requested by the client is not
    supported by the server, the connection will be rejected (for example,
    this would occur if the client requested protocol version 4.0, which does
    not exist as of this writing).  If the minor version requested by the
    client is not supported by the server (e.g., the client requests version
    3.2, but the server supports only 3.0), the server may either reject the
    connection or may respond with a NegotiateProtocolVersion message
    containing the highest minor protocol version which it supports.  The
    client may then choose either to continue with the connection using the
    specified protocol version or to abort the connection.
   </para>

   <para>
    The protocol