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
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 |