agora inbox for [email protected]
help / color / mirror / Atom feedFrom: Jim Nasby <[email protected]>
To: Tom Lane <[email protected]>
Cc: Peter Eisentraut <[email protected]>
Cc: Robert Haas <[email protected]>
Cc: Pg Hackers <[email protected]>
Cc: David E. Wheeler <[email protected]>
Subject: Re: Very confusing installcheck behavior with PGXS
Date: Thu, 7 Jan 2016 12:50:16 -0600
Message-ID: <[email protected]> (raw)
In-Reply-To: <[email protected]>
References: <[email protected]>
<CA+TgmoaKJFjY-=A6x3Qhk2Sf7egQG3=FdSUdzTCQtogYbBGyCQ@mail.gmail.com>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
<[email protected]>
List-Unsubscribe: <mailto:[email protected]?body=unsub%20pgsql-hackers>
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 ([email protected])
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
view thread (19+ messages) latest in thread
reply
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: [email protected]
Cc: [email protected], [email protected], [email protected], [email protected], [email protected]
Subject: Re: Very confusing installcheck behavior with PGXS
In-Reply-To: <[email protected]>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by agora; see mirroring instructions
for how to clone and mirror all data and code used for this inbox