From: | Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com> |
---|---|
To: | peter(dot)eisentraut(at)2ndquadrant(dot)com |
Cc: | michael(at)paquier(dot)xyz, pgsql-hackers(at)lists(dot)postgresql(dot)org |
Subject: | Re: Expand the use of check_canonical_path() for more GUCs |
Date: | 2020-05-21 01:11:26 |
Message-ID: | 20200521.101126.1920637563482949610.horikyota.ntt@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
At Wed, 20 May 2020 10:05:29 +0200, Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Ranier Vilela | 2020-05-21 01:37:36 | Re: Parallel Seq Scan vs kernel read ahead |
Previous Message | Michael Paquier | 2020-05-21 00:32:55 | Re: Adding missing object access hook invocations |