Subject: Re: Very confusing installcheck behavior with PGXS
To: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>
References: <56899F36.9000607@BlueTreble.com>
 <CA+TgmoaKJFjY-=A6x3Qhk2Sf7egQG3=FdSUdzTCQtogYbBGyCQ@mail.gmail.com>
 <5651.1452102882@sss.pgh.pa.us>
CC: Pg Hackers <pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <568E7829.2050805@BlueTreble.com>
Date: Thu, 7 Jan 2016 08:37:29 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:38.0)
 Gecko/20100101 Thunderbird/38.5.0
MIME-Version: 1.0
In-Reply-To: <5651.1452102882@sss.pgh.pa.us>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Received-SPF: None (protection.outlook.com: bluetreble.com does not designate
 permitted sender hosts)
SpamDiagnosticOutput: 1:23
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Jan 2016 14:37:35.4575 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR11MB0680
X-Pg-Spam-Score: -1.9 (-)
List-Archive: <http://archives.postgresql.org/pgsql-hackers>
List-Help: <mailto:majordomo@postgresql.org?body=help>
List-ID: <pgsql-hackers.postgresql.org>
List-Owner: <mailto:pgsql-hackers-owner@postgresql.org>
List-Post: <mailto:pgsql-hackers@postgresql.org>
List-Subscribe: <mailto:majordomo@postgresql.org?body=sub%20pgsql-hackers>
List-Unsubscribe: <mailto:majordomo@postgresql.org?body=unsub%20pgsql-hackers>
X-Mailing-List: pgsql-hackers
Precedence: bulk
Sender: pgsql-hackers-owner@postgresql.org

On 1/6/16 11:54 AM, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
>> On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>>> The rule that gets executed if you do `make installcheck` with something
>>> using PGXS is
>>>
>>> pgxs.mk:        $(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS)
>>>
>>> where $(pg_regress_installcheck) is set in Makefile.global.in to
>>>
>> pg_regress_installcheck = $(top_builddir)/src/test/regress/pg_regress
>> --inputdir=$(srcdir) --bindir='$(bindir)' $(pg_regress_locale_flags)
>> $(EXTRA_REGRESS_OPTS)
>>>
>>> The problem here is that in a PGXS make, srcdir is set to '.'[1], and
>>> --inputdir is specified a second time in REGRESS_OPTS. Normally that works
>>> OK (for some reason ignoring what's in ./sql), but if you happen to have a
>>> file in your test/sql directory that matches a file in ./sql, pg_regress
>>> runs the first file and not the second.
>
>> Stupid question time: why in the world would you have that?

It doesn't seem that odd to have a test file that matches an extension 
file...

> AFAICS, the pieces we supply (Makefile.global and pgxs.mk) would only
> specify --inputdir once.  If there's a second specification being added
> to REGRESS_OPTS by your own Makefile, that would override the default,
> which seems like entirely sensible behavior.  Maybe I'm misunderstanding
> something, but it sounds like you're saying "if I write --inputdir=test
> in REGRESS_OPTS, it runs the tests in test/sql not those in ./sql".
> Why would you not think that's expected?

Actually, it's more bizarre than I thought...

This is what my makefile[1] produces, which currently works:
/Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/regress/pg_regress 
--inputdir=./ --bindir='/Users/decibel/pgsql/HEAD/i/bin' 
--inputdir=test --load-language=plpgsql --dbname=contrib_regression 
acl_type build compat rights

Removing the first --inputdir also works:
/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_type build 
compat rights

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.

I'd assumed this was due to the extra --inputdir option, but clearly 
something else is going on here.

Time to gvim pg_regress.c...

[1] https://github.com/decibel/pg_acl
-- 
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