Re: Expand the use of check_canonical_path() for more GUCs

On 2020-06-03 20:45, Tom Lane wrote:
> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>> On Tue, Jun 2, 2020 at 5:04 AM Peter Eisentraut
>> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>>> The archeology reveals that these calls where originally added to
>>> canonicalize the data_directory and config_file settings (7b0f060d54),
>>> but that was then moved out of guc.c to be done early during postmaster
>>> startup (337ffcddba). The remaining calls of check_canonical_path() in
>>> guc.c appear to be leftovers from a previous regime.
>
>> Thanks for looking into it. Sounds like it can just be ripped out,
>> then, unless someone knows of a reason to do otherwise.
>
> In the abstract, I agree with Peter's point that we shouldn't alter
> user-given strings without need. However, I think there's strong
> reason for canonicalizing the data directory and config file locations.

It is not proposed to change that. It is only debated whether the same
canonicalization should be applied to other GUCs that represent paths.

> We access those both before and after chdir'ing into the datadir, so
> we'd better have absolute paths to them --- and at least for the
> datadir, it's documented that you can initially give it as a path
> relative to wherever you started the postmaster from. If the other
> files are only accessed after the chdir happens then we could likely
> do without canonicalizing them. But ... do we know which directory
> the user (thought he) specified them with reference to? Forced
> canonicalization does have the advantage that it's clear to all
> onlookers how we are interpreting the paths.

This (and some other messages in this thread) appears to assume that
canonicalize_path() turns relative paths into absolute paths, but
AFAICT, it does not do that.

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