From: | Robert Treat <rob(at)xzilla(dot)net> |
---|---|
To: | Fujii Masao <masao(dot)fujii(at)gmail(dot)com> |
Cc: | Daniel Gustafsson <daniel(at)yesql(dot)se>, pgsql-docs(at)lists(dot)postgresql(dot)org |
Subject: | Re: Index / glossary adjustments for Git & GUC |
Date: | 2025-08-15 04:12:57 |
Message-ID: | CAJSLCQ3ZpgA6d3RNbzz6h4Gv=xR70ZTgF65ayS7eDZrd_UhN2A@mail.gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs |
On Wed, Aug 13, 2025 at 10:48 PM Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Wed, Aug 13, 2025 at 5:04 PM Daniel Gustafsson <daniel(at)yesql(dot)se> wrote:
> > > On 13 Aug 2025, at 01:16, Robert Treat <rob(at)xzilla(dot)net> wrote:
> >
> > > The first patch removes the term "Git" from the acronyms section and
> > > instead creates an index entry that points to our source repository
> > > information.
> >
> > This was previously discussed in this thread:
> >
> > https://postgr.es/m/8241CED6-F408-4660-A1AA-F3393AA26219%40yesql.se
> >
> > > For the second, ISTM we use the term GUC to refer to parameters pretty
> > > liberally, but the term is not that easy to find in the docs (and
> > > website search gives what is probably the best answer as result #7 of
> > > 8). This creates an index entry for the term, as well as a glossary
> > > entry which explains how it is commonly used.
> >
> > This seems like a good idea.
>
> +1
>
> + <glossentry id="glossary-guc">
> + <glossterm>GUC</glossterm>
>
> Should we also include the full term "Grand Unified Configuration" here, e.g.,
> "Grand unified configuration (GUC)", similar to how "Log sequence number (LSN)"
> is shown in the glossary? Even though it's already in the acronyms docs,
> it might be helpful to include it in the glossary as well.
>
So when I first wrote this, I wrote the following:
Originally a short-hand for Grand Unified Configuration, the subsystem
which controls PostgreSQL server configuration, it is now a commonly
used term for the individual configuration parameters themselves.
While typically meant to refer to user settable parameters, it can
also refer to internal or build-time parameters.
That felt a little verbose, and ISTM the more important part was
focusing on GUCs as postgres jargon for parameters rather than
explaining the history (which as you noted is explained elsewhere),
but I can see the argument for completeness over clarity.
Robert Treat
https://xzilla.net
From | Date | Subject | |
---|---|---|---|
Next Message | Hayato Kuroda (Fujitsu) | 2025-08-15 04:46:17 | RE: Make pgoutput documentation easier to find |
Previous Message | Chao Li | 2025-08-15 01:44:29 | Re: Make pgoutput documentation easier to find |