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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
