temporary-installation method, pass the appropriate
     locale-related environment variables on
     the <command>make</command> command line, for example:
<programlisting>
make check LANG=de_DE.utf8
</programlisting>
     (The regression test driver unsets <envar>LC_ALL</envar>, so it
     does not work to choose the locale using that variable.)  To use
     no locale, either unset all locale-related environment variables
     (or set them to <literal>C</literal>) or use the following
     special invocation:
<programlisting>
make check NO_LOCALE=1
</programlisting>
     When running the tests against an existing installation, the
     locale setup is determined by the existing installation.  To
     change it, initialize the database cluster with a different
     locale by passing the appropriate options
     to <command>initdb</command>.
    </para>

    <para>
     In general, it is advisable to try to run the
     regression tests in the locale setup that is wanted for
     production use, as this will exercise the locale- and
     encoding-related code portions that will actually be used in
     production.  Depending on the operating system environment, you
     might get failures, but then you will at least know what
     locale-specific behaviors to expect when running real
     applications.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-date-time-differences">
    <title>Date and Time Differences</title>

    <para>
     Most of the date and time results are dependent on the time zone
     environment.  The reference files are generated for time zone
     <literal>America/Los_Angeles</literal>, and there will be
     apparent failures if the tests are not run with that time zone setting.
     The regression test driver sets environment variable
     <envar>PGTZ</envar> to <literal>America/Los_Angeles</literal>,
     which normally ensures proper results.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-float-differences">
    <title>Floating-Point Differences</title>

    <para>
     Some of the tests involve computing 64-bit floating-point numbers (<type>double
     precision</type>) from table columns. Differences in
     results involving mathematical functions of <type>double
     precision</type> columns have been observed.  The <literal>float8</literal> and
     <literal>geometry</literal> tests are particularly prone to small differences
     across platforms, or even with different compiler optimization settings.
     Human eyeball comparison is needed to determine the real
     significance of these differences which are usually 10 places to
     the right of the decimal point.
    </para>

    <para>
     Some systems display minus zero as <literal>-0</literal>, while others
     just show <literal>0</literal>.
    </para>

    <para>
     Some systems signal errors from <function>pow()</function> and
     <function>exp()</function> differently from the mechanism
     expected by the current <productname>PostgreSQL</productname>
     code.
    </para>
   </sect2>

   <sect2 id="regress-evaluation-ordering-differences">
    <title>Row Ordering Differences</title>

    <para>
You might see differences in which the same rows are output in a
different order than what appears in the expected file.  In most cases
this is not, strictly speaking, a bug.  Most of the regression test
scripts are not so pedantic as to use an <literal>ORDER BY</literal> for every single
<literal>SELECT</literal>, and so their result row orderings are not well-defined
according to the SQL specification.  In practice, since we are
looking at the same queries being executed on the same data by the same
software, we usually get the same result ordering on all platforms,
so the lack of <literal>ORDER BY</literal> is not a problem.  Some queries do exhibit
cross-platform ordering differences, however.  When testing against an
already-installed server, ordering differences can also be caused by
non-C locale settings or non-default