Re: Expand the use of check_canonical_path() for more GUCs - Mailing list pgsql-hackers

From Kyotaro Horiguchi
Subject Re: Expand the use of check_canonical_path() for more GUCs
Date
Msg-id 20200521.101126.1920637563482949610.horikyota.ntt@gmail.com
Whole thread Raw
In response to Re: Expand the use of check_canonical_path() for more GUCs  (Peter Eisentraut <peter.eisentraut@2ndquadrant.com>)
List pgsql-hackers
At Wed, 20 May 2020 10:05:29 +0200, Peter Eisentraut <peter.eisentraut@2ndquadrant.com> wrote in 
> On 2020-05-20 09:13, Michael Paquier wrote:
> > On Tue, May 19, 2020 at 01:02:12PM +0200, Peter Eisentraut wrote:
> >> That thread didn't resolve why check_canonical_path() is necessary
> >> there.
> >> Maybe the existing uses could be removed?
> > This would impact log_directory, external_pid_file,
> > stats_temp_directory, where it is still useful to show to the user
> > cleaned up names, no?  See for example 2594cf0.
> 
> I don't understand why we need to alter the file names specified by
> the user.  They presumably wrote them that way for a reason and they
> probably like them that way.
> 
> There are specific situations where we need to do that to know whether
> a path is in the data directory or the same as some other one etc.
> But unless there is a reason like that, I think we should just leave
> them.

I completely agree to Peter here.  I would be surprised that I see
system views show different strings from what I wrote in config
files. I also think that it ought to be documented if we store tweaked
string for a user input.

regards.

-- 
Kyotaro Horiguchi
NTT Open Source Software Center



pgsql-hackers by date:

Previous
From: Michael Paquier
Date:
Subject: Re: Adding missing object access hook invocations
Next
From: Ranier Vilela
Date:
Subject: Re: Parallel Seq Scan vs kernel read ahead