Horton

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

Tom Lane <tgl@sss.pgh.pa.us>

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Eisentraut <peter.eisentraut@2ndquadrant.com>
Cc: Noah Misch <noah@leadboat.com>, Andrew Dunstan <andrew@dunslane.net>, pgsql-hackers@postgresql.org
Date: 2017-08-01T02:18:34Z
Lists: pgsql-hackers 
Peter Eisentraut <peter.eisentraut@2ndquadrant.com> writes:
> On 7/31/17 16:54, Tom Lane wrote:
>> Maybe "which" isn't the best tool for the job, not sure.

> Yeah, "which" is not portable.  This would need a bit more work and
> portability testing.

Fair enough.  This late in beta is probably not the time to be adding new
portability testing needs.  However, I noticed that some places --- not
consistently everywhere --- were solving this with the low-tech method of
just skipping AC_PATH_PROG if the variable is already set.  We could apply
that hack more consistently by inventing a PGAC_PATH_PROGS wrapper macro
as I previously sketched, but for now just defining it as

# Let the user override the search for $1
if test -z "$$1"; then
  AC_PATH_PROGS($@)
fi

(untested, but you get the idea).  In the long run I would like to improve
this to force the supplied value into absolute-path form, but I'd be
content to ship v10 like that.

			regards, tom lane

Commits

  1. Adjust configure to insist on Perl version >= 5.8.3.

  2. Further improve consistency of configure's program searching.

  3. Doc: specify that the minimum supported version of Perl is 5.8.3.

  4. Record full paths of programs sought by "configure".

  5. Abandon the use of Perl's Safe.pm to enforce restrictions in plperl, as it is