pg_regress in C - Mailing list pgsql-patches

From Magnus Hagander
Subject pg_regress in C
Date
Msg-id 6BCB9D8A16AC4241919521715F4D8BCEA0FAFD@algol.sollentuna.se
Whole thread Raw
Responses Re: pg_regress in C  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: pg_regress in C  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-patches
Per discussion at the conference:

In order to run the regression tests on Windows without msys, pg_regress
needs to be reimplemnted in C. There are two reasons to want this:

1) To be able to build completely without mingw (which can be a pain to
install if you're not lucky) - build pg with visual c++, run tests
directly with pg_regress.

2) To be able to ship the regression tests with the installer, where we
really can't expect msys to exist. The reason for this is twofold in
turn - one is to simply allow a way to "prove to PHBs that the installed
version works", and realistically also to test that linked-in DLLs that
we don't ship somehow broke the system. It could happen...



This implementation only replaces the shellscript with a C program. It
still uses psql to execute the queries (thus testing psql as well), and
shells to "diff" to generate diffs. (having to ship diff on win32 is
still not perfect, but a *lot* better than msys/mingw). I have tried to
keep things as similar as possible for now - possible enhancements that
can be done in C but not in SH can be added at a later time.

I have so far test on win32 (running "make installcheck" equivalent with
a MSVC-compiled backend) and on Linux (running "make check" equivalent),
with no problems. I haven't modified the Makefile, so it need to be run
manually. The commandline is almost the same - needs an added --platform
set to the value that's available in the Makefile only. A "bindir"
parameter has been added to be able to run it on an installed system not
in the system PATH.

To use regexp, this code links with regcomp.c and regexec.c from
src/backend/regex, and with wstrncmp.c from src/backend/utils/mb. I have
not updated the Makefile yet, I don't know if we'd want to just link
with the .o files or copy in the .c ones (might be an issue for the
regex ones which include other .c files). I've been building it in a
completely separate sourcetree.


The code still needs some cleanup (for example making the error messages
more in line with our messaging guidlines), but I wanted to get this
submitted as soon as possible because of the upcoming feature freeze. In
a couple of days I will only have sporadic internet access for several
weeks, and thus won't be able to work on updates during that time. I'm
therefor hopeing to get this submitted and catch some early comments
now. Hopefully it will be enough to get it on the queue and then I can
fix whatever issues are when I get back to full connectivity. Unless,
that is, the whole approach seems wrong, in which case there's not much
point to me working on it anyway :-)

(I know, not the best of planning, but that's how feature-freeze-date
turned out for me :-( Sorry..)


//Magnus


Note: This version does not implement max_connections. From what I can
tell that's only used to workaround some bug in cygwin shells, which
shouldn't appear anymore after this is used. Not tested, have no working
cygwin env and haven't managed to install one..

Attachment

pgsql-patches by date:

Previous
From: "Joshua D. Drake"
Date:
Subject: Update to external_projects.sgml
Next
From: "Joachim Wieland"
Date:
Subject: Time zone definitions to config files