On Tue, Aug 20, 2024 at 12:10:08PM -0400, Tom Lane wrote: > ... which would also imply writing documentation and so forth, > and it'd mean that injection_points starts to show up in end-user > installations. (That would happen with the alternative choice of > hacking install-world to include src/test/modules/injection_points, > too.) While you could argue that that'd be helpful for extension > authors who'd like to use injection_points in their own tests, I'm > not sure that it's where we want to go with that module. It's only > meant as test scaffolding, and I don't think we've analyzed the > implications of some naive user installing it.
The original line of thoughts here is that if I were to write a test that relies on injection points for a critical bug fix, then I'd rather not have to worry about the hassle of maintaining user-facing documentation to get the work done. The second line is that we should be able to tweak the module or even break its ABI as much as we want in stable branches to accomodate to the tests, which is what a test module is good for. The same ABI argument kind of stands as well for the backend portion, but we'll see where it goes. > We do, however, need to preserve the property that installcheck > works after install-world. I'm starting to think that maybe > the 041 test should be hacked to silently skip if it doesn't > find injection_points available. (We could then remove some of > the makefile hackery that's supporting the current behavior.) > Probably the same needs to happen in each other test script > that's using injection_points --- I imagine that Maxim's > test is simply failing here first. Yeah, we could do that. -- Michael
signature.asc
Description: PGP signature