<varname>in_hot_standby</varname> were not reported by releases before
       14; <varname>scram_iterations</varname> was not reported by releases
       before 16; <varname>search_path</varname> was not reported by releases
       before 18.)
       Note that
       <varname>server_version</varname>,
       <varname>server_encoding</varname> and
       <varname>integer_datetimes</varname>
       cannot change after startup.
      </para>

      <para>
       If no value for <varname>standard_conforming_strings</varname> is reported,
       applications can assume it is <literal>off</literal>, that is, backslashes
       are treated as escapes in string literals.  Also, the presence of
       this parameter can be taken as an indication that the escape string
       syntax (<literal>E'...'</literal>) is accepted.
      </para>

      <para>
       Although the returned pointer is declared <literal>const</literal>, it in fact
       points to mutable storage associated with the <literal>PGconn</literal> structure.
       It is unwise to assume the pointer will remain valid across queries.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQfullProtocolVersion">
     <term><function>PQfullProtocolVersion</function><indexterm><primary>PQfullProtocolVersion</primary></indexterm></term>

     <listitem>
      <para>
       Interrogates the frontend/backend protocol being used.
<synopsis>
int PQfullProtocolVersion(const PGconn *conn);
</synopsis>
       Applications might wish to use this function to determine whether certain
       features are supported. The result is formed by multiplying the server's
       major version number by 10000 and adding the minor version number. For
       example, version 3.2 would be returned as 30002, and version 4.0 would
       be returned as 40000. Zero is returned if the connection is bad. The 3.0
       protocol is supported by <productname>PostgreSQL</productname> server
       versions 7.4 and above.
      </para>
      <para>
       The protocol version will not change after connection startup is
       complete, but it could theoretically change during a connection reset.
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQprotocolVersion">
     <term><function>PQprotocolVersion</function><indexterm><primary>PQprotocolVersion</primary></indexterm></term>

     <listitem>
      <para>
       Interrogates the frontend/backend protocol major version.
<synopsis>
int PQprotocolVersion(const PGconn *conn);
</synopsis>
       Unlike <xref linkend="libpq-PQfullProtocolVersion"/>, this returns only
       the major protocol version in use, but it is supported by a wider range
       of libpq releases back to version 7.4. Currently, the possible values are
       3 (3.0 protocol), or zero (connection bad). Prior to release version
       14.0, libpq could additionally return 2 (2.0 protocol).
      </para>
     </listitem>
    </varlistentry>

    <varlistentry id="libpq-PQserverVersion">
     <term><function>PQserverVersion</function><indexterm><primary>PQserverVersion</primary></indexterm></term>

     <listitem>
      <para>
       Returns an integer representing the server version.
<synopsis>
int PQserverVersion(const PGconn *conn);
</synopsis>
      </para>

      <para>
       Applications might use this function to determine the version of the
       database server they are connected to.  The result is formed by
       multiplying the server's major version number by 10000 and adding
       the minor version number.  For example, version 10.1 will be
       returned as 100001, and version 11.0 will be returned as 110000.
       Zero is returned if the connection is bad.
      </para>

      <para>
       Prior to major version 10, <productname>PostgreSQL</productname> used
       three-part version numbers in which the first two parts together
       represented the major version.  For those
       versions, <xref linkend="libpq-PQserverVersion"/>