pg_regress writes into source tree
When using a vpath build pg_regress writes the processed input/*.source
files into the *source* tree, which isn't supposed to happen.
This appears to be a thinko introduced in this patch:
e3fc4a97bc8ee82a78605b5ffe79bd4cf3c6213b
The attached patch fixes it.
Attachments:
regress-outputdir.patchapplication/x-patch; name=regress-outputdir.patchDownload
diff --git a/src/test/regress/pg_regress.c b/src/test/regress/pg_regress.c
index 27c46ab..8683035 100644
--- a/src/test/regress/pg_regress.c
+++ b/src/test/regress/pg_regress.c
@@ -611,7 +611,7 @@ convert_sourcefiles_in(char *source_subdir, char *dest_dir, char *dest_subdir, c
static void
convert_sourcefiles(void)
{
- convert_sourcefiles_in("input", inputdir, "sql", "sql");
+ convert_sourcefiles_in("input", outputdir, "sql", "sql");
convert_sourcefiles_in("output", outputdir, "expected", "out");
}
Peter Eisentraut wrote:
When using a vpath build pg_regress writes the processed input/*.source
files into the *source* tree, which isn't supposed to happen.This appears to be a thinko introduced in this patch:
e3fc4a97bc8ee82a78605b5ffe79bd4cf3c6213b
Oh, I noticed this while doing the dummy_seclabel move to
src/test/modules and I thought it was on purpose; if I'm not
mistaken this is why we had to add the .sql file to .gitignore.
Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.
--
�lvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Hi,
On 2014-12-11 22:02:26 -0500, Peter Eisentraut wrote:
When using a vpath build pg_regress writes the processed input/*.source
files into the *source* tree, which isn't supposed to happen.This appears to be a thinko introduced in this patch:
e3fc4a97bc8ee82a78605b5ffe79bd4cf3c6213bThe attached patch fixes it.
I've been annoyed by this more than once, specifically when trying to
run tests with different compilation settings at once...
Greetings,
Andres Freund
--
Andres Freund http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.
+1 for having pg_regress create the sql/ directory when it does not
exist. Current behavior is annoying when modules having only tests in
input/...
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.+1 for having pg_regress create the sql/ directory when it does not
exist. Current behavior is annoying when modules having only tests in
input/...
That seems like a separate issue. I think Peter should commit his patch
and backpatch it immediately, and we can deal with the missing sql
directory when someone sends in a patch.
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
On 12/18/2014 06:05 PM, Andrew Dunstan wrote:
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir
if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.+1 for having pg_regress create the sql/ directory when it does not
exist. Current behavior is annoying when modules having only tests in
input/...That seems like a separate issue. I think Peter should commit his
patch and backpatch it immediately, and we can deal with the missing
sql directory when someone sends in a patch.
What's happened on this?
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
On Sat, Feb 14, 2015 at 6:24 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 12/18/2014 06:05 PM, Andrew Dunstan wrote:
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.+1 for having pg_regress create the sql/ directory when it does not
exist. Current behavior is annoying when modules having only tests in
input/...That seems like a separate issue. I think Peter should commit his patch
and backpatch it immediately, and we can deal with the missing sql directory
when someone sends in a patch.What's happened on this?
Nothing has been committed, and as far as I understood this patch
could have been simply pushed...
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On 2/13/15 11:20 PM, Michael Paquier wrote:
On Sat, Feb 14, 2015 at 6:24 AM, Andrew Dunstan <andrew@dunslane.net> wrote:
On 12/18/2014 06:05 PM, Andrew Dunstan wrote:
On 12/18/2014 03:02 AM, Michael Paquier wrote:
On Fri, Dec 12, 2014 at 10:45 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:Another thing in that patch was that I had to add the sql/ directory to
the source tree, but other than that .gitignore file it was empty.
Maybe pg_regress should create the sql/ directory in the build dir if it
doesn't exist. This is only a problem if a pg_regress suite only runs
stuff from input/, because otherwise the sql/ dir already exists in the
source.+1 for having pg_regress create the sql/ directory when it does not
exist. Current behavior is annoying when modules having only tests in
input/...That seems like a separate issue. I think Peter should commit his patch
and backpatch it immediately, and we can deal with the missing sql directory
when someone sends in a patch.What's happened on this?
Nothing has been committed, and as far as I understood this patch
could have been simply pushed...
Just so this doesn't get lost... did something make it into a CommitFest
on this?
--
Jim Nasby, Data Architect, Blue Treble Consulting
Data in Trouble? Get it in Treble! http://BlueTreble.com
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
On Wed, Apr 8, 2015 at 10:28 AM, Jim Nasby wrote:
Just so this doesn't get lost... did something make it into a CommitFest on
this?
Peter's patch has been committed as 64cdbbc, while the idea to create
sql/ by pg_regress if it is not present did not gather much interest
in this CF:
https://commitfest.postgresql.org/4/100/
--
Michael
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers