Re: Very confusing installcheck behavior with PGXS - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Very confusing installcheck behavior with PGXS
Date
Msg-id 12117.1452190333@sss.pgh.pa.us
Whole thread Raw
In response to Re: Very confusing installcheck behavior with PGXS  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
Responses Re: Very confusing installcheck behavior with PGXS  (Jim Nasby <Jim.Nasby@BlueTreble.com>)
List pgsql-hackers
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> If we want to keep input/ and output/ inside pg_regress then I think 
> what needs to happen in a vpath build is to first create $vpath/sql and 
> $vpath/expected, copy anything from $(uh... source?)/sql and /expected 
> there, and then process /input and /output (and deal with any duplicate 
> file references).

No, I don't think we want to physically copy anything we don't have to.
(Before the commit I mentioned upthread, we were actually doing it more
or less as you suggest, and it was messy.)

I'm not really concerned about the current behavior of putting transformed
input/output files into sql/ and expected/.  Only experts are likely to
be creating files requiring transformation at all (and even the experts
prefer to avoid that, because they're a PITA).  So I am not very worried
about duplication of file names between eg input/ and sql/.  But I don't
like handling VPATH by introducing confusion between --inputdir and
--outputdir.

It does strike me though that some of your pain is self-inflicted: why
did you think it was a good idea to create both test/sql/ and sql/
subdirectories?  What's the point of test/ at all?  It's certainly not
part of the standard layout for a contrib module.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Jim Nasby
Date:
Subject: Re: Very confusing installcheck behavior with PGXS
Next
From: Jeff Janes
Date:
Subject: Re: No Issue Tracker - Say it Ain't So!