Re: pgsql: Adjust configure to insist on Perl version >= 5.8.3.

On Thu, Oct 07, 2021 at 03:44:48PM -0400, Tom Lane wrote:
> [ cc'ing Craig and Noah, as author/committer of the existing text ]
>
> Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> > On 7 Oct 2021, at 21:02, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> >> BTW, looking at that a second time, I wonder if that advice is
> >> really of any use.
> >>
> >> (1) I'm distrustful of the idea that perl 5.8.x will compile
> >> cleanly, or at all, on modern platforms. Certainly Postgres
> >> releases of similar vintage won't.

perlbrew uses the patchperl system to build old Perl in modern environments.
This year, I used it to get 5.8.0. Building unpatched 5.8.0 does fail.

> >> (2) Unless perlbrew.pl is doing something a lot more magic than
> >> I think, you're going to end up with current-not-historical
> >> versions of whatever it has to pull from CPAN. That's going
> >> to include at least IPC::Run and Test::More if you want to run
> >> our TAP tests.

Yes. If someone changed the recipe to install Test::More 0.87 and the
oldest-acceptable IPC::Run, we'd detect more portability problems. I'd regard
such a change as an improvement.

> >> So maybe this advice is helpful, but I'm not very convinced.

The rest of this thread is leaning on the above misconceptions:

> I propose that what might be more useful than the existing last
> section of src/test/perl/README is something along the lines of:
>
> Avoid using any bleeding-edge Perl features. We have buildfarm
> animals running Perl versions as old as 5.8.3, so your tests will
> be expected to pass on that.
>
> Also, do not use any non-core Perl modules except IPC::Run.
> Or, if you must do so for a particular test, arrange to skip
> the test when the needed module isn't present.

-1. This would replace a useful recipe with, essentially, a restatement of
that recipe in English words. That just leaves the user to rediscover the
actual recipe.