Re: PL_stashcache, or, what's our minimum Perl version?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andrew Dunstan <andrew(at)dunslane(dot)net>
Cc: pgsql-hackers(at)postgreSQL(dot)org
Subject: Re: PL_stashcache, or, what's our minimum Perl version?
Date: 2017-07-30 05:21:28
Message-ID: 16894.1501392088@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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".
> And the lack of field complaints suggests strongly that nobody else
> cares. So I'm inclined to think we just need to be more specific
> about the minimum Perl version --- but what exactly?

I've done some more research on this. It seems to me there are four
distinct components to any claim about whether we work with a particular
Perl version:

1. Can it run the build-related Perl scripts needed to build PG from
a bare git checkout, on non-Windows platforms?
2. Can it run our MSVC build scripts?
3. Does pl/perl compile (and pass its regression tests) against it?
4. Can it run our TAP tests?

I have no info to offer about point #2, but I did some tests with
ancient 5.8.x Perl versions on my buildfarm hosts prairiedog and
gaur. (I would have liked to use something faster, but these Perl
versions failed to build at all on more recent platforms, and
I thought it rather pointless to try to hack them enough to build.)

I find that perl 5.8.0 and later seem to succeed at point #1,
but you need at least 5.8.1 to compile plperl. Also, on prairiedog
5.8.1 fails plperl's regression tests because of some seemingly
utf8-related bug. That may be an ancient-macOS problem more than
anything else, so I didn't poke at it too hard.

The really surprising thing I found out is that you can't run the
TAP tests on anything older than 5.8.3, because that's when they
added "prove". I'm bemused by the idea that such a fundamental
facility would get added in a third-digit minor release, but there
you have it. (Now, in fairness, this amounted to importing a feature
that already existed on CPAN, but still...)

5.8.3 does appear to succeed at points 1,3,4. Now, to get through
the TAP tests you need to install IPC::Run, and you also need to
update Test::More because the version shipped with 5.8.3 is too old.
But at least the failures that you get from lacking these are pretty
clear.

I am unable to confirm our claim that we work with Test::More 0.82,
because CPAN has only versions from a year or three back. (Anyone
know of a more, er, comprehensive archive than CPAN?) It's also
interesting to speculate about how old a version of IPC::Run is new
enough, but I see no easy way to get much data on that either.

Anyway, pending some news about compatibility of the MSVC scripts,
I think we ought to adjust our docs to state that 5.8.3 is the
minimum supported Perl version.

Also, I got seriously confused at one point during these tests because,
while our configure script carefully sets PERL to an absolute path name,
it's content to set PROVE to "prove", paying no attention to whether
that version of "prove" matches "perl". Is it really okay to run the
TAP tests with a different perl version than we selected for other
purposes? I think it'd be a good idea to insist that "prove" be in
the same directory we found "perl" in.

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2017-07-30 05:26:50 Re: GSoC 2017: Foreign Key Arrays
Previous Message Jeevan Ladhe 2017-07-30 02:37:01 Re: Adding support for Default partition in partitioning