On 1/7/16 9:56 AM, Tom Lane wrote:
Jim Nasby <jim.na...@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
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:

Reply via email to