modular pg_regress.sh

I propose a patch to make pg_regress.sh more modular. I'd like to do
ecpg regression tests for my soc project and don't want to duplicate
functionality. I put those parts of the code that parse the command line
and set up the environment variables and the database into sh-functions
and moved them to a separate file. pg_regress.sh then includes this
file and calls these functions as any other regression framework can
then do.

The patch adds a new file pg_regress.inc.sh.in.

Before there was:

pg_regress.sh -> (replacements) -> pg_regress

now I have:

pg_regress.inc.sh.in -> (replacements) -> pg_regress.inc.sh
There is nothing to replace in pg_regress.sh so I made that get called
for the regression tests instead of pg_regress.

The patch also adds a new option, --listen-on-tcp that makes the server
listen on the tcp port even when unix sockets can be used.


There were two issues I noticed with the old script:

DROP regressionuser[1-3], regressiongroup1 was done previously before
running the tests, that is, after creating the regression database and
before installing PLs into it.  The only effect of this that I can see
is that if a regression test aborts in privileges.sql and does use an
already running server then the next run could lead to a failed
privileges test. If privileges.sql gets executed completely then it will
clean up anyway in the end which makes lingering roles from this test
quite unprobable. I kept the behavior however but do the cleanup now
at the beginning of the very privileges.sql.

Next, this comment seems to be not true anymore:

  # ----------
  # Set backend timezone and datestyle explicitly
  #
  # To pass the horology test in its current form, the postmaster must be
  # started with PGDATESTYLE=ISO, while the frontend must be started with
  # PGDATESTYLE=Postgres.  We set the postmaster values here and change
  # to the frontend settings after the postmaster has been started.
  # ----------

  PGTZ='PST8PDT'; export PGTZ
  PGDATESTYLE='ISO, MDY'; export PGDATESTYLE

It seems that the affected regression tests set those values already in
the .sql files. Also note that if this was true, you couldn't use an
already running server without special adaptions.


Joachim