On 1/7/16 12:12 PM, Tom Lane wrote:
> 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.
Maybe I'm just confused... what should happen then in a vpath build? Do
the results of input/*.source get put in sql/ in the source tree?
Oh, I guess there's magic that looks first in $source/sql and then in
$vpath/sql?
One thing I'm in violent agreement on is there's way too much magic
happening here. That magic isn't even hinted at by --help, and since
there's no documentation on pg_regress extension authors can only follow
other examples here...
> 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.
I blame David Wheeler, who I copied the pattern from. :) Actually, I got
the pattern from pgxntool, which AFAIK got the pattern from him.
Regardless of blame, the problem I see is that extensions frequently
deal with nothing but sql, and mixing up your test code with your
extension code is going to be confusing and messy. So instead of piling
everything into /sql, David decided to put the test stuff in /test and
leave the sql stuff in /sql (if there's C files those tend to go in /src).
I see a lot of extensions using this pattern (or something similar). The
other common pattern I see is to just pile everything into the top level
extension directory. That's OK at first (and for a really, really simple
extension might be all you ever want), but if you start having a few
tests, a doc file, and several upgrade scripts that starts getting messy.
--
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
