On Tue, Jun 16, 2026 at 12:20:12PM -0400, Tom Lane wrote:
> Jacob Champion <jacob.champion@enterprisedb.com> 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
