From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Peter Eisentraut <peter_e(at)gmx(dot)net>, Robert Haas <robertmhaas(at)gmail(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Very confusing installcheck behavior with PGXS |
Date: | 2016-01-07 17:43:02 |
Message-ID: | 568EA3A6.7080309@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/7/16 9:56 AM, Tom Lane wrote:
> Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-01-07 17:45:30 | Re: pglogical_output - a general purpose logical decoding output plugin |
Previous Message | Tom Lane | 2016-01-07 17:39:19 | Re: Multi-tenancy with RLS |