Alvaro Herrera <alvherre@commandprompt.com> writes:
> Tom Lane wrote:
>> Who decided this part of pg_regress.c was a good idea?
> Hmm, AFAICS it was applied by me in 1.26, a patch from Magnus
> apparently. This was quite some time ago! I think I just passed that
> part verbatim from Magnus' patch.
Hmm ... I wonder if the unstated agenda was to run the regression tests
without having any supporting Makefile?
I'd be willing to make it #ifdef WIN32, instead of diking it out entirely,
if that's what the problem is. I would prefer to remove it though.
The original design had only the Makefile knowing exactly where the
testtablespace directory lurks, making it changeable in one place,
and also confining the whole business to src/test/regress which is good
because none of the other uses of pg_regress need it. As CVS tip
stands, the location of testtablespace is hard-wired into the pg_regress
executable, and I think it's mostly blind accident that it doesn't
clutter contrib/* and src/pl/* with testtablespace directories.
At this point what I'd really prefer is that pg_regress be completely
uninvolved with testtablespace, which we could manage by getting rid
of @testtablespace@ in the regression test files in favor of
@abs_builddir@/testtablespace. This would mean that both the Makefile
and the regression test files know where the directory lurks, but either
of those are easier to change than a precompiled binary.
Now this isn't gonna work if there's a prerequisite for pg_regress
to execute without any external setup, but surely we don't expect
users to enter all its switch arguments by hand. What's the actual
intended arrangement on Windows ... is there a .BAT script or something
that could make the directory?
regards, tom lane