On July 19, 4:52 am Tom Lane [EMAIL PROTECTED] wrote:
Joachim Wieland [EMAIL PROTECTED] 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
---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
