On Sat, Nov 29, 2014 at 5:54 AM, Alvaro Herrera
<alvherre(at)2ndquadrant(dot)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