Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Alvaro Herrera
David E. Wheeler wrote: > On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote: > > >>> Also worth noting: the only reason I'm using pg_regress is it's the > >>> easiest > >>> way to get a test cluster. If not for that, I'd just use pg_prove since > >>> I'm > >>> already using pgTap. > >> > >> In 9.5

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread David E. Wheeler
On Jan 7, 2016, at 11:20 AM, Jim Nasby wrote: >>> Also worth noting: the only reason I'm using pg_regress is it's the easiest >>> way to get a test cluster. If not for that, I'd just use pg_prove since I'm >>> already using pgTap. >> >> In 9.5 you might want to "use PostgresNode" which allows yo

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
On 1/7/16 1:04 PM, Alvaro Herrera wrote: Jim Nasby wrote: Also worth noting: the only reason I'm using pg_regress is it's the easiest way to get a test cluster. If not for that, I'd just use pg_prove since I'm already using pgTap. In 9.5 you might want to "use PostgresNode" which allows you t

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Alvaro Herrera
Jim Nasby wrote: > Also worth noting: the only reason I'm using pg_regress is it's the easiest > way to get a test cluster. If not for that, I'd just use pg_prove since I'm > already using pgTap. In 9.5 you might want to "use PostgresNode" which allows you to initdb and such. -- Álvaro Herrera

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
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 PI

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Tom Lane
Jim Nasby 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

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
On 1/7/16 9:56 AM, Tom Lane wrote: Jim Nasby writes: On 1/7/16 9:12 AM, Tom Lane wrote: (I'm also wondering how convert_sourcefiles() works at all in a vpath build, considering that I don't see it doing anything like this ...) It's only looking at outputdir, which I suspect is never ambiguo

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Tom Lane
Jim Nasby writes: > On 1/7/16 9:12 AM, Tom Lane wrote: >> (I'm also wondering how convert_sourcefiles() works at all in a vpath >> build, considering that I don't see it doing anything like this ...) > It's only looking at outputdir, which I suspect is never ambiguous. Eh, no, look again. What

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
On 1/7/16 9:12 AM, Tom Lane wrote: Jim Nasby writes: On 1/7/16 8:47 AM, Tom Lane wrote: That's pretty hard to believe. There's nothing in pg_regress that looks in places other than the given --inputdir. Actually, I think it does... from pg_regress_main.c: /* * Look for

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Tom Lane
Jim Nasby writes: > On 1/7/16 8:47 AM, Tom Lane wrote: >> That's pretty hard to believe. There's nothing in pg_regress that looks >> in places other than the given --inputdir. > Actually, I think it does... from pg_regress_main.c: > /* >* Look for files in the output dir first, co

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
On 1/7/16 8:47 AM, Tom Lane wrote: Jim Nasby writes: However, if I do this: mv test/sql/acl_type.sql test/sql/acl.sql mv test/expected/acl_type.out test/expected/acl.out And change acl_type to acl in that pg_regress command: /Users/decibel/pgsql/HEAD/i/lib/pgxs/src/makefiles/../../src/test/r

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-07 Thread Jim Nasby
On 1/6/16 11:54 AM, Tom Lane wrote: Robert Haas writes: On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote: The rule that gets executed if you do `make installcheck` with something using PGXS is pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) where $(pg_regress_installche

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-06 Thread Tom Lane
Robert Haas writes: > On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote: >> The rule that gets executed if you do `make installcheck` with something >> using PGXS is >> >> pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) >> >> where $(pg_regress_installcheck) is set in Makefi

Re: [HACKERS] Very confusing installcheck behavior with PGXS

2016-01-06 Thread Robert Haas
On Sun, Jan 3, 2016 at 5:22 PM, Jim Nasby wrote: > The rule that gets executed if you do `make installcheck` with something > using PGXS is > > pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) > > where $(pg_regress_installcheck) is set in Makefile.global.in to > >> pg_regress

[HACKERS] Very confusing installcheck behavior with PGXS

2016-01-03 Thread Jim Nasby
The rule that gets executed if you do `make installcheck` with something using PGXS is pgxs.mk:$(pg_regress_installcheck) $(REGRESS_OPTS) $(REGRESS) where $(pg_regress_installcheck) is set in Makefile.global.in to pg_regress_installcheck = $(top_builddir)/src/test/regress/pg_regress