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

From: Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>
To: Mark Dilger <mark(dot)dilger(at)enterprisedb(dot)com>
Cc: Michael Paquier <michael(at)paquier(dot)xyz>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: Expand the use of check_canonical_path() for more GUCs
Date: 2020-05-29 18:14:44
Message-ID: 20200529181444.GA2940@alvherre.pgsql
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On 2020-May-28, Mark Dilger wrote:

> A little poking around shows that in SelectConfigFiles(), these four
> directories were set by SetConfigOption(). I don't see a problem with
> the code, but the way this stuff is spread around makes it easy for
> somebody adding a new GUC file path to do it wrong. I don't have much
> opinion about Peter's preference that paths be left alone, but I'd
> prefer some comments in guc.c explaining it all. The only cleanup
> that occurs to me is to reorder ConfigureNamesString[] to have all the
> path options back-to-back, with the four that are set by
> SelectConfigFiles() at the top with comments about why they are
> special, and the rest after that with comments about why they need or
> do not need canonicalization.

No need for reorganization, I think, just have a comment on top of each
entry that doesn't use canonicalization such as "no canonicalization,
as explained in ..." where that refers to a single largish comment that
explains what canonicalization is, why you use it, and why you don't.

--
Álvaro Herrera https://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Justin Pryzby 2020-05-29 18:25:15 Re: proposal: possibility to read dumped table's name from file
Previous Message David G. Johnston 2020-05-29 17:40:54 Re: pg_dump fail to not dump public schema orders