Re: Bug in pg_dump - Mailing list pgsql-hackers

From Stephen Frost
Subject Re: Bug in pg_dump
Date
Msg-id 20150301182525.GC29780@tamriel.snowman.net
Whole thread Raw
In response to Re: Bug in pg_dump  (Michael Paquier <michael.paquier@gmail.com>)
Responses Re: Bug in pg_dump  (Stephen Frost <sfrost@snowman.net>)
List pgsql-hackers
Michael,

* Michael Paquier (michael.paquier@gmail.com) wrote:
> >> Subject: [PATCH 2/3] Make prove_check install contents of current directory as well
> >
> > This is really an independent thing, no?  I don't see any particular
> > problem with it, for my part.
>
> Yes, that's an independent thing, but my guess is that it would be
> good to have a real test case this time to be sure that this does not
> break again, at least on master where test/modules is an ideal place.

I've been looking at this, but noticed the following in
src/test/Makefile:

# We want to recurse to all subdirs for all standard targets, except that
# installcheck and install should not recurse into the subdirectory "modules".

Also, adding a few more items to the Makefile makes the regression tests
pass:

+ MODULE_big = dump_test
+ REGRESS = dump_test

So I'm thinking this isn't really necessary?

I've not really looked into it further but my hunch is the difference is
a pgxs build vs. a non-pgxs build (which I think might be what the
regression suite runs..).  One or both of the above might be necessary
to make non-pgxs builds work.

I've made a few other modifications to the test (basically, I wrapped
all the commands run in command_ok() since it wasn't actually failing
when I was expecting it to and plan to include it in the commit to
master.
Thanks!
    Stephen

pgsql-hackers by date:

Previous
From: Stephen Frost
Date:
Subject: Re: Improving RLS qual pushdown
Next
From: Dean Rasheed
Date:
Subject: Re: Improving RLS qual pushdown