Re: no test programs in contrib

Peter Eisentraut wrote:
> On 11/27/14 3:10 PM, Tom Lane wrote:
> > I'm not too happy with that approach, because packagers are going to
> > tend to think they should package any files installed by install-world.
> > The entire point of this change, IMO, is that the test modules should
> > *not* get installed, certainly not by normal install targets. Being
> > consistent with the existing contrib packaging is exactly not what we
> > want.
>
> I share this objection.

Okay, the attached version does it that way.

I also attach some changes for the MSVC build stuff. I tested it and it
builds fine AFAICT, but it doesn't install because Install.pm wants to
install contrib modules from contrib/ (which seems reasonable) but my
hack adds the src/test/modules/ as contrib modules also, so Install.pm
goes bonkers. I'm not even sure *what* we're supposed to build -- there
is no distinction in these programs as there is in the makefiles about
what to install. So if some Windows developer can look into this, I'd
appreciate it.

> But the existing main regression tests are able to run against an
> existing installation while using the modules autoinc.so and refint.so
> without installing them. I think the problem is that we are able to
> load a .so file from just about anywhere, but we can't load a full
> extension in the same way. There have been discussions about that, in
> the context of being able to test an externally developed extension
> before/without installing it. This is pretty much the same case.

I'm leaving that problem for someone else to solve.

Andres Freund wrote:
> On 2014-11-27 15:51:51 -0500, Tom Lane wrote:
> >
> > If we follow that reasoning we'll end up removing nothing from contrib.
> > There is no reason that end users should need to be performing such
> > testing; anyone who does have reason to do it will have a source tree
> > at hand.
>
> Actually I don't think that's true for test_decoding - there's quite a
> bit of actual things that you can do with it. At the very least it's
> useful to roughly measure the impact logical replication would have on a
> database, but it's also helpful to look at the changes. And even if the
> format isn't super nice, thanks to Robert's insistence it's actually
> safely parseable if necessary.

Argh. Okay, the attached doesn't move test_decoding either.

I think it's fine anyway -- I'm sure we will come up with a few
additional test modules, such as the one for the commit_ts patch.

--
Álvaro Herrera http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services