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

From: Peter Eisentraut <peter(dot)eisentraut(at)2ndquadrant(dot)com>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Expand the use of check_canonical_path() for more GUCs
Date: 2020-06-02 09:04:42
Message-ID: 44af92e9-7458-14d6-01e7-5bcd0b3adaec@2ndquadrant.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-05-29 19:24, Robert Haas wrote:
> On Tue, May 19, 2020 at 7:02 AM Peter Eisentraut
> <peter(dot)eisentraut(at)2ndquadrant(dot)com> wrote:
>> That thread didn't resolve why check_canonical_path() is necessary
>> there. Maybe the existing uses could be removed?
>
> This first sentence of this reply seems worthy of particualr
> attention. We have to know what problem this is intended to fix before
> we try to decide in which cases it's needed. Otherwise, whether we add
> it everywhere or remove it everywhere, we'll only know that it's
> consistent, not that it's correct.

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.

--
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 Andy Fan 2020-06-02 09:04:50 Re: Hybrid Hash/Nested Loop joins and caching results from subplans
Previous Message Peter Eisentraut 2020-06-02 08:57:40 Re: OpenSSL 3.0.0 compatibility