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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
Cc: Noah Misch <noah(at)leadboat(dot)com>, Andrew Dunstan <andrew(at)dunslane(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: PL_stashcache, or, what's our minimum Perl version?
Date: 2017-08-01 02:18:34
Message-ID: 15282.1501553914@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2017-08-01 02:44:08 Re: Update description of \d[S+] in \?
Previous Message Robert Haas 2017-08-01 02:10:52 Re: [PATCH v3] pg_progress() SQL function to monitor progression of long running SQL queries/utilities