| 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: | Whole Thread | Raw Message | 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. |