On Mon, 4 Mar 2024 at 23:23, Michael Paquier <mich...@paquier.xyz> wrote: > In my experience, anybody who does serious testing with their product > integrated with Postgres have two or three types of builds with their > own scripts: one with assertions, -DG and other developer-oriented > options enabled, and one for production deployments with more > optimized options like -O2. Once there are custom scripts to build > and package Postgres, do we really need to move that to contrib/ at > all?
I do think there is quite a bit of a difference from a user perspective to providing a few custom configure flags and having to go to a separate directory and run "make install" there too. Simply because it's yet another step. For dev environments most/all of my team uses pgenv: https://github.com/theory/pgenv There I agree we could add functionality to it to also install test modules when given a certain flag/environment variable, but it would be nice if that wasn't needed. One big downside to not having it in contrib is that we also run tests of Citus against official PGDG postgres packages and those would likely not include these test modules, so we wouldn't be able to run all our tests then. Also I think the injection points extension is quite different from the other modules in src/modules/test. All of these other modules are basically test binaries that need to be separate modules, but they don't provide any useful functionality when installing them. The injection_poinst one actually provides useful functionality itself, that can be used by other people testing things against postgres. > make install would work for a test module as long as the command > is run locally in its directory. What would I need to do for meson builds? I tried the following command but it doesn't seem to actually install the injection points command: ninja -C build install-test-files
