Update now-obsolete example of platform-specific regression comparison

files.
This commit is contained in:
Tom Lane 2001-08-06 22:53:26 +00:00
parent bf51b8608b
commit af3487e9bf
1 changed files with 21 additions and 28 deletions

View File

@ -1,4 +1,4 @@
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.17 2001/03/20 00:09:36 tgl Exp $ -->
<!-- $Header: /cvsroot/pgsql/doc/src/sgml/regress.sgml,v 1.18 2001/08/06 22:53:26 tgl Exp $ -->
<chapter id="regress">
<title id="regress-title">Regression Tests</title>
@ -49,7 +49,7 @@
<screen>
<computeroutput>
======================
All 76 tests passed.
All 77 tests passed.
======================
</computeroutput>
</screen>
@ -176,15 +176,24 @@
<sect2>
<title>Date and time differences</title>
<para>
Some of the queries in the <quote>timestamp</quote> test will
fail if you run the test on the day of a daylight-savings time
changeover, or the day before or after one. These queries assume
that the intervals between midnight yesterday, midnight today and
midnight tomorrow are exactly twenty-four hours -- which is wrong
if daylight-savings time went into or out of effect meanwhile.
</para>
<para>
Most of the date and time results are dependent on the time zone
environment. The reference files are generated for time zone
PST8PDT (Berkeley, California) 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>PST8PDT</literal> to ensure
proper results. However, your system must provide library
<envar>PGTZ</envar> to <literal>PST8PDT</literal>, which normally
ensures proper results. However, your system must provide library
support for the PST8PDT time zone, or the time zone-dependent
tests will fail. To verify that your machine does have this
support, type the following:
@ -214,15 +223,6 @@ PGTZ='PST8PDT7,M04.01.0,M10.05.03'; export PGTZ
pre-1970 PDT times to be displayed in PST instead. This will
result in localized differences in the test results.
</para>
<para>
Some of the queries in the <quote>timestamp</quote> test will
fail if you run the test on the day of a daylight-savings time
changeover, or the day before or after one. These queries assume
that the intervals between midnight yesterday, midnight today and
midnight tomorrow are exactly twenty-four hours -- which is wrong
if daylight-savings time went into or out of effect meanwhile.
</para>
</sect2>
<sect2>
@ -363,24 +363,17 @@ testname/platformpattern=comparisonfilename
</para>
<para>
For example: the int2 regression test includes a deliberate entry
of a value that is too large to fit in int2. The specific error
message that is produced is platform-dependent; our reference
platform emits
<screen>
<computeroutput>ERROR: pg_atoi: error reading "100000": Numerical result out of range</computeroutput>
</screen>
but a fair number of other Unix platforms emit
<screen>
<computeroutput>ERROR: pg_atoi: error reading "100000": Result too large</computeroutput>
</screen>
For example: some systems using older time zone libraries fail to apply
daylight-savings corrections to dates before 1970, causing
pre-1970 PDT times to be displayed in PST instead. This causes a
few differences in the <filename>horology</> regression test.
Therefore, we provide a variant comparison file,
<filename>int2-too-large.out</filename>, that includes this
spelling of the error message. To silence the bogus
<filename>horology-no-DST-before-1970.out</filename>, which includes
the results to be expected on these systems. To silence the bogus
<quote>failure</quote> message on HPPA platforms, resultmap
includes
<programlisting>
int2/hppa=int2-too-large
horology/hppa=horology-no-DST-before-1970
</programlisting>
which will trigger on any machine for which config.guess's output
begins with <quote><literal>hppa</literal></quote>. Other lines