Re: no test programs in contrib
От | Michael Paquier |
---|---|
Тема | Re: no test programs in contrib |
Дата | |
Msg-id | CAB7nPqT2wEEUU90VajtvsA-g16FTCDeZUaz0PiSBzVtCX1nJNw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: no test programs in contrib (Alvaro Herrera <alvherre@2ndquadrant.com>) |
Список | pgsql-hackers |
On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera <alvherre@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
Вложения
В списке pgsql-hackers по дате отправления: