On 1/7/16 8:47 AM, Tom Lane wrote:
Jim Nasby <jim.na...@bluetreble.com> writes:
However, if I do this:
mv test/sql/acl_type.sql test/sql/acl.sql
mv test/expected/acl_type.out test/expected/acl.out

And change acl_type to acl in that pg_regress command:
/Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress
--bindir='/Users/decibel/pgsql/HEAD/i/bin' --inputdir=test
--load-language=plpgsql --dbname=contrib_regression acl build compat rights

Instead of executing test/sql/acl.sql, it executes ./sql/acl.sql.

That's pretty hard to believe.  There's nothing in pg_regress that looks
in places other than the given --inputdir.

Actually, I think it does... from pg_regress_main.c:

        /*
         * Look for files in the output dir first, consistent with a vpath 
search.
         * This is mainly to create more reasonable error messages if the file 
is
         * not found.  It also allows local test overrides when running 
pg_regress
         * outside of the source tree.
         */
        snprintf(infile, sizeof(infile), "%s/sql/%s.sql",
                         outputdir, testname);
        if (!file_exists(infile))
                snprintf(infile, sizeof(infile), "%s/sql/%s.sql",
                                 inputdir, testname);

If I add --outputdir=test, then everything works fine.

Obviously I can just deal with this in my Makefile, but is this really the behavior we want? It certainly seems to violate POLA...

I wonder whether you have a test/input/acl.sql and/or test/output/acl.out
that's confusing matters.

Nope...

decibel@decina:[08:35]~/git/pg_acl (master *%=)$ll test
total 16
drwxr-x---   6 decibel  staff  204 Jan  2 17:31 ./
drwxr-x---  17 decibel  staff  578 Jan  7 08:35 ../
-rw-r-----   1 decibel  staff   65 Jan  2 17:31 deps.sql
drwxr-x---   6 decibel  staff  204 Jan  7 08:32 expected/
lrwxr-x--- 1 decibel staff 25 Dec 26 13:43 pgxntool@ -> ../pgxntool/test/pgxntool
drwxr-x---   6 decibel  staff  204 Jan  7 08:32 sql/
decibel@decina:[08:48]~/git/pg_acl (master *%=)$


--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Experts in Analytics, Data Architecture and PostgreSQL
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

Reply via email to