Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version? - Mailing list pgsql-hackers

From Tom Lane
Subject Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?
Date
Msg-id 24665.1501214288@sss.pgh.pa.us
Whole thread Raw
In response to [HACKERS] PL_stashcache, or, what's our minimum Perl version?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: [HACKERS] PL_stashcache, or, what's our minimum Perl version?
List pgsql-hackers
I wrote:
> So the question is, does anyone care?  I wouldn't except that our
> documentation appears to claim that we work with Perl "5.8 or later".

BTW, what actually says that is installation.sgml:
     <application>Perl</> 5.8 or later is needed to build from a Git checkout,     or if you changed the input files
forany of the build steps that     use Perl scripts.  If building on Windows you will need     <application>Perl</> in
anycase.  <application>Perl</application> is     also required to run some test suites. 

Strictly speaking, there is no statement anywhere (AFAICT) about what
Perl versions PL/Perl works with.

As an experiment, I built from a "make maintainer-clean" state using
that 5.8.0 install, and it worked.  So indeed installation.sgml's
statement is correct as far as it goes.  But I dunno what the situation
is for the MSVC build scripts.  I did not try the TAP tests either.

A look in the buildfarm logs says that the oldest Perl version we're
actually testing is 5.8.6 on prairiedog.  (castoroides/protosciurus
have 5.8.4 but they are not building --with-perl, so that only
exercises the build scripts not plperl; they're not doing TAP either.)
I only looked into configure.log results though, so I'm not sure
about the Windows critters.

I kinda suspect we're not actively testing non-MULTIPLICITY builds
either.  The 5.8.7 test I just ran was with a non-MULTIPLICITY build,
so the case doesn't seem actively broken, but I doubt there is any
buildfarm coverage.  I wonder if it'd be worth getting the buildfarm
to log the output of "perl -V" so we could get a clearer picture
of what's being tested.
        regards, tom lane



pgsql-hackers by date:

Previous
From: Craig Ringer
Date:
Subject: Re: [HACKERS] On Complex Source Code Reading Strategy
Next
From: Masahiko Sawada
Date:
Subject: Re: [HACKERS] Refreshing subscription relation state inside atransaction block