Re: no test programs in contrib

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Peter Eisentraut <peter_e(at)gmx(dot)net>, Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>, Josh Berkus <josh(at)agliodbs(dot)com>
Subject: Re: no test programs in contrib
Date: 2014-11-28 20:54:53
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

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 wants to
install contrib modules from contrib/ (which seems reasonable) but my
hack adds the src/test/modules/ as contrib modules also, so
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 and
> 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
PostgreSQL Development, 24x7 Support, Training & Services

Attachment Content-Type Size
test_modules_4.patch text/x-diff 27.5 KB
test_modules_4-msvc.patch text/x-diff 5.1 KB

In response to


Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2014-11-28 20:55:31 Re: bug in json_to_record with arrays
Previous Message Josh Berkus 2014-11-28 20:44:17 Re: no test programs in contrib