On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera <alvhe...@2ndquadrant.com> wrote: > 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. When src/test/modules is compiled directly after running ./configure, make complains about utils/errcodes.h missing: In file included from worker_spi.c:23: In file included from ../../../../src/include/postgres.h:48: ../../../../src/include/utils/elog.h:69:10: fatal error: 'utils/errcodes.h' file not found #include "utils/errcodes.h"
Shouldn't src/test/modules/Makefile includes .PHONY with submake-errcodes like for example in the patch attached? Regards, -- Michael
diff --git a/src/test/modules/Makefile b/src/test/modules/Makefile index 93d93af..7ca3eb0 100644 --- a/src/test/modules/Makefile +++ b/src/test/modules/Makefile @@ -11,6 +11,7 @@ SUBDIRS = \ test_shm_mq \ test_parser +.PHONY: submake-errcodes all: submake-errcodes submake-errcodes:
-- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers