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

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

In response to

Browse pgsql-hackers by date

  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