On Sun, July 30, 2017 12:22 pm, Tom Lane wrote:
> "Tels" <> writes:
>> On Sun, July 30, 2017 1:21 am, Tom Lane 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".
>> Not sure how often People use old Perl versions out in the field. I'd
>> venture this is either happens with "ancient" stuff, e.g. where people
>> just can't or want upgrade.
>> Otherwise, an up-to-date OS is just necessary for security, anyway, and
>> that would contain a Perl from this decade, wouldn't it?
> Well, that's not really the point, IMO.  The reason I'm interested in
> this is the same reason I run some buildfarm critters on ancient
> platforms: if we do something that breaks backwards compatibility
> with old software, we should know it and make a deliberate decision
> that it's okay.  (And update the relevant compatibility claims in our
> docs.)  Moving the compatibility goalposts without knowing it isn't
> good, especially if it happens in supposedly-stable release branches.

Sure, I was just pointing out that moving the goalpost forward knowingly,
as you put it, can be ok vs. trying to support ancient software at all
costs. Reads to me as we are in agreement here.

>>> 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.
>> Test::More has been bundled with Perl since 5.6.2 (you can use
>> "corelist"
>> to check for these things), so if all fails, it might be possible to
>> extract a version from a Perl distribution [4].
> Yeah, I looked into that.  The closest candidate I can find is that
> perl 5.10.1 contains Test::More 0.92.  However, it's not real clear
> to me exactly which files I'd need to pull out of 5.10.1 and inject into
> an older tarball --- the layout seems a lot different from a standalone
> package.

Module distributions contain a MANIFEST like this:

And while reconstructing a module for an old version can be quite a
hassle,, it looks like Test::More is just plain Perl and only uses

So basically the two files:

might do the trick. Unless PG uses also Test::Simple or other modules,
which I haven't check, then you just need to add these, too.

And basically, you put these files into a subdirectory, and use:

  use lib "mydir";

to tell Perl to load modules from there first.

Here is a sample archive with a modern Test::More and an old Test::More
from 5.10.1. There are two scripts to see how they are loaded and used.

One thing to watch out is that this would use the old Test::More, but any
module it loads (or the script use) comes from the system Perl. So the
test might not be 100% complete accurate, f.i. if a newer IO::Scalar is
used with the old Test::More.

You could also compile and install an old Perl version into a local
subdirectory and test with that. That takes a bit more time, though.

Hope this helps,


Sent via pgsql-hackers mailing list (
To make changes to your subscription:

Reply via email to