On Wed, 6 Mar 2024 at 07:17, Michael Paquier <mich...@paquier.xyz> wrote: > 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.
There's quite a few developer-oriented GUCs as well, even requiring their own DEVELOPER_OPTIONS section. So I don't think it's too weird to have some developer-oriented extensions too. > 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. That seems fine, if people need more functionality they can indeed create their own test helpers. It mainly seems annoying for people to have to copy-paste the ones from core to their own extension. What I mainly meant is that anything in src/test/modules is not even close to somewhat useful for other people to use. They are really just very specific tests that need to be written in C. Afaict all those modules are not even used by tests outside of their own module. But these functions are helper functions, to be used by other tests. And limiting the users of those helper functions to just be in-core Postgres code seems a bit annoying. I feel like these functions are more akin to the pgregress/isolationtester binaries in their usage, than akin to other modules in src/test/modules. > 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. Quite a few contrib modules have very limited documentation. I think it would be fine for this as well. > This should just need -Dinjection_points=true. Ugh... Sorry... I didn't realize that it needed a dedicated configure flag. When providing that flag it indeed installs the expected files. I guess that rules out testing against PGDG packages, because those packages almost certainly wouldn't specify this flag.
