Subject: Re: Very confusing installcheck behavior with PGXS
To: Tom Lane <tgl@sss.pgh.pa.us>
References: <56899F36.9000607@BlueTreble.com>
 <CA+TgmoaKJFjY-=A6x3Qhk2Sf7egQG3=FdSUdzTCQtogYbBGyCQ@mail.gmail.com>
 <5651.1452102882@sss.pgh.pa.us> <568E7829.2050805@BlueTreble.com>
 <12108.1452178021@sss.pgh.pa.us> <568E7B4A.4080003@BlueTreble.com>
 <13036.1452179541@sss.pgh.pa.us> <568E8317.3000806@BlueTreble.com>
 <29567.1452182165@sss.pgh.pa.us>
CC: Peter Eisentraut <peter_e@gmx.net>, Robert Haas <robertmhaas@gmail.com>,
 Pg Hackers <pgsql-hackers@postgresql.org>
From: Jim Nasby <Jim.Nasby@BlueTreble.com>
Message-ID: <568EA3A6.7080309@BlueTreble.com>
Date: Thu, 7 Jan 2016 11:43:02 -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: <29567.1452182165@sss.pgh.pa.us>
Content-Type: text/plain; charset="windows-1252"; 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 17:43:05.8143 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR11MB0684
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/7/16 9:56 AM, Tom Lane wrote:
> Jim Nasby <Jim.Nasby@bluetreble.com> writes:
>> On 1/7/16 9:12 AM, Tom Lane wrote:
>>> (I'm also wondering how convert_sourcefiles() works at all in a vpath
>>> build, considering that I don't see it doing anything like this ...)
>
>> It's only looking at outputdir, which I suspect is never ambiguous.
>
> Eh, no, look again.  What it's actually doing is reading $inputdir/input/
> and converting into $outputdir/sql/, and reading $inputdir/output/ and
> converting into $outputdir/expected/.  I guess that works, but again it's
> kind of at variance with the normal expectation of VPATH behavior.  What
> you'd expect is that $builddir/input files would override $srcdir/input
> files; but as is, $builddir/input and $builddir/output are never examined
> at all.

Yeah, I just discovered the whole input/ and output/ bit. That really 
complicates things, because ISTM it's very common to directly specify 
both sql/ and expected/ files directly, and you'd certainly THINK that 
those files are input, and not output.

Which begs the question... how the hell do sql/ and expected/ ever work 
in a vpath build? AFAICT things are never copied from 
$inputdir/(sql|expected) to $outputdir...

Maybe it's just me, but this whole convention seems like a giant POLA 
violation. If pg_regress was only used in Postgres source maybe that 
wouldn't matter since presumably there's always an example to copy from 
(and presumably tests use either input/ and output/ OR sql/ and 
expected/, but never both). But pg_regress is used by contrib and now 
extensions, so it's got a much wider audience than just -hackers. :/

input and output are used in only 3 places in the whole tree[1], so 
maybe the best thing to do is just rip support for that out of 
pg_regress and handle it some other way.

Also worth noting: the only reason I'm using pg_regress is it's the 
easiest way to get a test cluster. If not for that, I'd just use 
pg_prove since I'm already using pgTap.

[1] find . \( -name input -o -name output \) -type d
./contrib/dblink/input
./contrib/dblink/output
./contrib/file_fdw/input
./contrib/file_fdw/output
./src/test/regress/input
./src/test/regress/output
-- 
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