On Tue, Mar 05, 2024 at 09:43:03AM +0100, Jelte Fennema-Nio wrote: > 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.
Didn't know this one, TBH. That's interesting. My own scripts emulate the same things with versioning, patching, etc. > 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. No idea about this part, unfortunately. One thing that I'd do is first check if the in-core module is enough to satisfy the requirements Citus would want. I got pinged about Timescale and greenplum recently, and they can reuse the backends APIs, but they've also wanted a few more callbacks than the in-core module so they will need to have their own code for tests with a custom callback library. Perhaps we could move that to contrib/ and document that this is a module for testing, that can be updated without notice even in minor upgrades and that there are no version upgrades done, or something like that. I'm open to that if there's enough demand for it, but I don't know how much we should accomodate with the existing requirements of contrib/ for something that's only developer-oriented. > 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. I'm not sure about that yet, TBH. Anything that gets added to this module should be used in some way by the in-core tests, or just not be there. That's a line I don't want to cross, which is why it's a test module. FWIW, it would be really annoying to have documentation requirements, actually, because that increases maintenance and I'm not sure it's a good idea to add a module maintenance on top of what could require more facility in the module to implement a test for a bug fix. > 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 Weird, that works here. I was digging into the meson tree and noticed that this was the only run_target() related to the test module install data, and injection_points gets installed as well as all the other modules. This should just need -Dinjection_points=true. -- Michael
signature.asc
Description: PGP signature
