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@yesql.se> writes:
> > On 7 Oct 2021, at 21:02, Tom Lane <tgl@sss.pgh.pa.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.