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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
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-07-31 19:17:36
Message-ID: 90a92a7d-938e-507a-3bd7-ecd2b4004689@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 7/31/17 14:55, Tom Lane wrote:
>> We use the "PATH" variants when we need a fully qualified name. For
>> example, at some point or another, we needed to substitute a fully
>> qualified perl binary name into the headers of scripts.
>
>> If there is no such requirement, then we should use the non-PATH variants.
>
> Why? That risks failures of various sorts, and you have not stated
> any actual benefit of it.

What I wrote is merely a description of the current practice. That
practice was in turn developed out of ancient Autoconf standard
practices. There are arguments to be made for doing it differently.

One major PITA with the AC_PATH_* checks is that you can only override
them with environment variables that are full paths; otherwise the
environment variables are ignored. For example, currently, running

./configure PYTHON=python3

will result in the PYTHON setting being ignored. Currently, this only
affects a small number of variables, but if we expanded that, it would
be a pretty significant usability change.

--
Peter Eisentraut http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2017-07-31 19:37:25 Re: PL_stashcache, or, what's our minimum Perl version?
Previous Message Stephen Frost 2017-07-31 19:13:24 Re: pg_stop_backup(wait_for_archive := true) on standby server