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

Joachim Wieland <joe(at)mcknight(dot)de> writes:
> I propose a patch to make pg_regress.sh more modular.

This patch has been pretty thoroughly superseded by the recent rewrite
of pg_regress in C. It's possible that we could modularize the C
version, but what I'd like to know first is why you can't just use
pg_regress as-is. If it's short a small feature or two, perhaps adding
those would be the way to go.

> 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.

I believe this is not necessary: just set --host='interface to listen on'.

> There were two issues I noticed with the old script:
> ...

These are good simplifications, which I've incorporated into CVS HEAD.

regards, tom lane

On July 19, 4:52 am Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Joachim Wieland <joe(at)mcknight(dot)de> writes:
> > I propose a patch to make pg_regress.sh more modular.
>
> This patch has been pretty thoroughly superseded by the recent rewrite
> of pg_regress in C. It's possible that we could modularize the C
> version, but what I'd like to know first is why you can't just use
> pg_regress as-is. If it's short a small feature or two, perhaps adding
> those would be the way to go.

My initial reason for doing this was ecpg testing. There, i'm interested in
the diffs of the actual .c file the precompiler creates as well as the
programm output when running it and the libecpg debug output.

I thought however that it would be nice to offer a kind of regression
framework, that lets you easily parse command line options, create a temp
environment (if desired), initialize the server with databases, roles,
languages, start up the server, clean up everything afterwards and so on.
This part probably is the same for any regression test, the only part that
differs is how the tests are actually run and what gets compared to what.

Not only ecpg could profit but also contrib modules and modules that are
not included in the distribution (like postgis for example or other stuff
on pgfoundry).

Joachim

"Joachim Wieland" <joe(at)mcknight(dot)de> writes:
> I thought however that it would be nice to offer a kind of regression
> framework, that lets you easily parse command line options, create a temp
> environment (if desired), initialize the server with databases, roles,
> languages, start up the server, clean up everything afterwards and so on.

Given that pg_regress is now in C (and only a few minutes ago did I stop
entertaining the idea of reverting that patch ... man, the Windows port
was painful), the way this would need to work is to split it into a
library and main program. Which isn't unreasonable if you feel like
doing the work. I'd suggest that at that point, pg_regress is no longer
some random thingie under src/test/regress, but would need to be
promoted to have its own source directory, perhaps under src/bin.

Also, we've speculated endlessly about developing a more general testing
framework that could for instance support serious testing of concurrent
behavior. Maybe here is a good place to start making that happen.

regards, tom lane