Re: Very confusing installcheck behavior with PGXS
От | Jim Nasby |
---|---|
Тема | Re: Very confusing installcheck behavior with PGXS |
Дата | |
Msg-id | 568EA775.2080509@BlueTreble.com обсуждение исходный текст |
Ответ на | Re: Very confusing installcheck behavior with PGXS (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Very confusing installcheck behavior with PGXS
|
Список | pgsql-hackers |
On 1/7/16 11:49 AM, Tom Lane wrote: > Jim Nasby <Jim.Nasby@bluetreble.com> writes: >> 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. > > [ raised eyebrow ] It's not apparent to me that moving it someplace else > would reduce the net cruft any. What it would do is de-mystify that part of pg_regress. I agree that vpath is a particular problem for input/ and output/, but it's even worse when most everyone thinks sql/ and expected/ are inputs to pg_regress, and not potential outputs. > The real problem is that Peter just did the minimum amount of work > to get VPATH to work at all, not to get it to work in a non-surprising > way. We really need this code to be explicitly VPATH-aware, I think, > rather than overloading the inputdir and outputdir concepts in > multiple ways. Agreed, especially because if it's not then if you try to use both input/ and sql/ or output/ and expected/ you're not going to get the results you'd like. 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). -- 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
В списке pgsql-hackers по дате отправления: