From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Daniel Gustafsson <daniel(at)yesql(dot)se> |
Cc: | Postgres hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Stale references to guc.c in comments/tests |
Date: | 2023-02-27 16:59:20 |
Message-ID: | 374597.1677517160@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Daniel Gustafsson <daniel(at)yesql(dot)se> writes:
> On 24 Feb 2023, at 16:19, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Perhaps you could use "the GUC mechanisms" in these places, but it's a bit
>> longer than "guc.c". Leaving such references alone seems OK too.
> I've opted for mostly leaving them in the attached v2.
This version seems OK to me except for this bit:
* This is a straightforward one-to-one mapping, but doing it this way makes
- * guc.c independent of OpenSSL availability and version.
+ * GUC definition independent of OpenSSL availability and version.
The grammar is a bit off ("the GUC definition" would read better),
but really I think the wording was vague already and we should tighten
it up. Can we specify exactly which GUC variable(s) we're talking about?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2023-02-27 17:02:03 | Re: pg_dump versus hash partitioning |
Previous Message | Robert Haas | 2023-02-27 16:57:04 | Re: pgsql: pg_rewind: Fix determining TLI when server was just promoted. |