On Tue, Jun 16, 2026 at 12:20:12PM -0400, Tom Lane wrote: > Jacob Champion <[email protected]> writes: >> It would probably be pretty easy to do that in slices. Backport the >> Python core, then develop the replacement for a segment of related >> tests as a reviewable and backportable chunk. That lets us refactor >> the testing APIs as we go, and if there are failures after backport, >> at least it's just that one area of the tests and not "the whole >> thing". > > Makes sense.
Backporting the core Python infrastructure sounds like a first mandatory step here. Under time-pressure with a release timeline, complicated/sensitive fixes may require tests across all the stable branches. Not having to translate the same test across two infrastructures would save a lot of brain resources. Backporting changes of the tests into the new Python infrastructure would make backpatching less complicated, indeed. It is much more common for me to add tests to existing scripts than create new ones. For a routine fix, I'd be OK to switch an existing test from perl to Python before doing a backpatch and expanding a script. Now, I don't think that we should close the door to the possibility of having to add some perl code in an existing perl script if we are under a time constraint (imagine in the security area). The only thing I'd argue to avoid is having to maintain two versions of the same test across *two* infrastructures. -- Michael
signature.asc
Description: PGP signature
