postgresql/src/test/regress

Introduction

  The Postgres95 regression tests are a comprehensive set of tests for the
  SQL implementation embeded in Postgres95 developed by Jolly Chen and
  Andrew Yu. It tests standard SQL operations as well as the extensability
  capabilities of Postgres95.

Preparation

  The regression test is invoked thru by the 'make' command which compiles
  a 'c' program with Postgres95 extension functions into a shared library
  in the current directory.  Localized shell scripts are also created in
  the current directory. The 'expected.input' file is massaged into the
  'expected.out' file.  The localization replaces macros in the source
  files with absolute pathnames and user names.

The 'expected.input' file and the 'sample.regress.out' file

  The 'expected.input' file was created on a SPARC Solaris 2.4 system
  using the 'postgres5-1.02a5.tar.gz' source tree. It has been compared
  with a file created on an I386 Solaris 2.4 system and the differences
  are only in the floating point polygons in the 3rd digit to the right
  of the decimal point. (see below)

  The 'sample.regress.out' file is from the postgres-1.01 release
  constructed by Jolly Chen and is included here for reference. It may
  have been created on a DEC ALPHA machine as the 'Makefile.global'
  in the postgres-1.01 release has PORTNAME=alpha.

Running the regression test

  Change directory to the regression test directory:

        cd ...../src/test/regress

  If you have prevously invoked the regression test, clean up the
  working directory with:

        make clean

  The regression test is invoked with the command:

        make all runtest

  Normally, the regression test should be run as the 'postgres' user as the
  'src/test/regress' directory and sub-directories are owned by the
  'postgres' user. If you run the regression test as another user the
  'src/test/regress' directory should be writeable to that user.

Comparing expected/actual output

  The results are in the file 'regress.out' which can be compared
  with the 'expected.out' file using 'diff'. The files will NOT
  compare exactly. The following paragraphs attempt to explain the
  differences.

OID differences

  There are several places where Postgres95 OID (object identifiers) appear
  in 'regress.out'. OID's are unique 32-bit integers which are generated
  by the Postgres95 backend whenever a table row is inserted or updated.
  If you run the regression test on a non-virgin database or run it multiple
  times, the OID's reported will have different values. 

  The following SQL statements in 'regress.out' have shown this behavior:

  QUERY: SELECT user_relns() AS user_relns ORDER BY user_relns;

    The 'a,523676' row is composed from an OID.

TIME differences

  Some of the tests involving date/time functions use the implicit
  time zone in effect at the time the regression test is run. In other
  tests the timezone to be inserted into the regression data base is
  explicitly specified.

  The 'expected.input' file was prepared in the 'US/Pacific' timezone
  so there may be differences where the 'expected.out' file has
  PST/PDT times and the 'regress.out' file has your local timezone.

FLOATING POINT differences

  Some of the tests involve computing 64-bit (FLOAT8) number from table
  columns. Differences in results involving mathematical functions of
  FLOAT8 columns have been observed. These differences occur where
  different operating systems are used on the same platform ie:
  BSDI and SOLARIS on Intel/86, and where the same operating system is
  used used on different platforms, ie: SOLARIS on SPARC and Intel/86.

  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.

POLYGON differences

  Several of the tests involve operations on geographic date about the
  Oakland/Berkley CA street map. The map data is expressed as polygons
  whose verticies are represened as pairs of FLOAT8 numbers (decimal
  lattitude and longitude). Initially, some tables are created and
  loaded with geographic data, then some views are created which join
  two tables using the polygon intersection operator (##), then a select
  is done on the view. 

  When comparing the results from different platforms, differences occur
  in the 2nd or 3rd place to the right of the decimal point. The SQL
  statements where these problems occur are the folowing:

    QUERY: SELECT * from street;
    QUERY: SELECT * from iexit;

DATE/TIME differences

  The Makefile attempts to adjust for timezone differences, but it is
  totally possible to eliminate them.  People outside North America
  will probabablly find the Makefile's adjustments are incorrect.  Also
  entries that use the time -infinity display with year 1970 plus/minus the
  number of hours you are different from GMT.