small regression adjustment
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
running pg_regress. Then we might be able to do thing like this, quite
independent of location:
\set datafile :inputdir/data/mystuff.data
COPY mytable FROM :'datafile';
The actual location would not need to appear in the SQL (and thus not in
the results file either).
A small patch that tries to do that is attached.
Thoughts?
cheers
andrew
Attachments:
regressdirs.patchtext/x-patch; name=regressdirs.patchDownload
diff --git a/src/test/regress/pg_regress_main.c b/src/test/regress/pg_regress_main.c
index a4f66b8..d47915b 100644
--- a/src/test/regress/pg_regress_main.c
+++ b/src/test/regress/pg_regress_main.c
@@ -64,9 +64,11 @@ psql_start_test(const char *testname,
"%s ", launcher);
snprintf(psql_cmd + offset, sizeof(psql_cmd) - offset,
- SYSTEMQUOTE "\"%s%spsql\" -X -a -q -d \"%s\" < \"%s\" > \"%s\" 2>&1" SYSTEMQUOTE,
+ SYSTEMQUOTE "\"%s%spsql\" -X -a -q -v \"inputdir=%s\" -v \"outputdir=%s\" -d \"%s\" < \"%s\" > \"%s\" 2>&1" SYSTEMQUOTE,
psqldir ? psqldir : "",
psqldir ? "/" : "",
+ inputdir,
+ outputdir,
dblist->str,
infile,
outfile);
Andrew Dunstan <andrew@dunslane.net> writes:
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
running pg_regress. Then we might be able to do thing like this, quite
independent of location:
\set datafile :inputdir/data/mystuff.data
COPY mytable FROM :'datafile';
If we could get rid of the run-time-generated-test-file facility
altogether, I could get excited about this; but just getting rid of
the COPY special cases isn't enough for that. Looking at
convert_sourcefiles_in, it seems like we'd also need solutions for
these dynamic substitutions:
replace_string(line, "@testtablespace@", testtablespace);
replace_string(line, "@libdir@", dlpath);
replace_string(line, "@DLSUFFIX@", DLSUFFIX);
At least this one seems rather difficult to fix in this fashion:
output/create_function_1.source:83:ERROR: could not find function "nosuchsymbol" in file "@libdir@/regress@DLSUFFIX@"
(I'm a bit inclined to think that we could dispense with @DLSUFFIX@
altogether; explicit use of the platform's library suffix has been
deprecated for at least a decade. But the others are harder.)
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 03/26/2014 11:37 AM, Tom Lane wrote:
Andrew Dunstan <andrew@dunslane.net> writes:
It occurred to me after having to change I think 9 files to clean up a
small mess in the jsonb regression tests the other day that we might
usefully expose the inputdir and outputdir to psql as variables when
running pg_regress. Then we might be able to do thing like this, quite
independent of location:
\set datafile :inputdir/data/mystuff.data
COPY mytable FROM :'datafile';If we could get rid of the run-time-generated-test-file facility
altogether, I could get excited about this; but just getting rid of
the COPY special cases isn't enough for that. Looking at
convert_sourcefiles_in, it seems like we'd also need solutions for
these dynamic substitutions:replace_string(line, "@testtablespace@", testtablespace);
replace_string(line, "@libdir@", dlpath);
replace_string(line, "@DLSUFFIX@", DLSUFFIX);At least this one seems rather difficult to fix in this fashion:
output/create_function_1.source:83:ERROR: could not find function "nosuchsymbol" in file "@libdir@/regress@DLSUFFIX@"
(I'm a bit inclined to think that we could dispense with @DLSUFFIX@
altogether; explicit use of the platform's library suffix has been
deprecated for at least a decade. But the others are harder.)
Well, maybe we should change dfmgr.c to stop outputting the DLSUFFIX in
its error message.
I haven't tried with the other two. I will when I get a spare moment.
But even if we find it too troublesome to get rid if the substitution
part altogether, I think minimizing the need for it would still be worth
doing. It would help extension authors, for example, who are most likely
to want to use it to load data files for testing their extensions.
cheers
andrew
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Andrew Dunstan <andrew@dunslane.net> writes:
On 03/26/2014 11:37 AM, Tom Lane wrote:
At least this one seems rather difficult to fix in this fashion:
output/create_function_1.source:83:ERROR: could not find function "nosuchsymbol" in file "@libdir@/regress@DLSUFFIX@"
(I'm a bit inclined to think that we could dispense with @DLSUFFIX@
altogether; explicit use of the platform's library suffix has been
deprecated for at least a decade. But the others are harder.)
Well, maybe we should change dfmgr.c to stop outputting the DLSUFFIX in
its error message.
If it weren't in the input command, it wouldn't be in the message either,
I think. It's the @libdir@ part of that that's problematic.
But even if we find it too troublesome to get rid if the substitution
part altogether, I think minimizing the need for it would still be worth
doing. It would help extension authors, for example, who are most likely
to want to use it to load data files for testing their extensions.
Yeah, I suppose getting down to one file needing a replacement would still
be a significant improvement over the current situation.
regards, tom lane
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers