Re: Very confusing installcheck behavior with PGXS
| От | Tom Lane |
|---|---|
| Тема | Re: Very confusing installcheck behavior with PGXS |
| Дата | |
| Msg-id | 12117.1452190333@sss.pgh.pa.us обсуждение |
| Ответ на | Re: Very confusing installcheck behavior with PGXS (Jim Nasby <Jim.Nasby@BlueTreble.com>) |
| Ответы |
Re: Very confusing installcheck behavior with PGXS
|
| Список | pgsql-hackers |
Jim Nasby <Jim.Nasby@bluetreble.com> writes:
> If we want to keep input/ and output/ inside pg_regress then I think
> what needs to happen in a vpath build is to first create $vpath/sql and
> $vpath/expected, copy anything from $(uh... source?)/sql and /expected
> there, and then process /input and /output (and deal with any duplicate
> file references).
No, I don't think we want to physically copy anything we don't have to.
(Before the commit I mentioned upthread, we were actually doing it more
or less as you suggest, and it was messy.)
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.
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.
regards, tom lane
В списке pgsql-hackers по дате отправления: