On Thu, 31 Oct 2024 at 18:15, Jelte Fennema-Nio <postgres@jeltef.nl> wrote:
>
> On Thu, 31 Oct 2024 at 15:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote:
> > Bikeshedding time:
>
> Another few options:
Okay let's just pick one of the available options. The current
situation where we use different terminology for the same thing across
the docs is definitely confusing, so let's change that. The proposed
options for the names are:
1. Protocol option
2. Protocol extension
3. Optional protocol feature
4. Protocol enhancement
5. Protocol flag
6. Protocol feature-flag
7. Protocol configuration
8. Protocol parameter
My personal preference from most to least preferred are as follows,
but I could live with any of them:
- 1
- 8
- 2
- 7
- everything else
(if we go for "protocol extension" then the patch should be updated to
include a section that clarifies that protocol extensions have nothing
to do with CREATE EXTENSION)
There are three places being changed here, and two things that may exist: a feature related to the protocol (reasonably called a protocol extension) and those pre-defined variables that take on values that those features may expose (presently called parameters in the context of the main server).
This is clearly the first thing:
- reserved for use as protocol extensions, while others are
+ reserved for use as protocol options, while others are
I would instead suggest "reserved for use *by* protocol extensions, while others are".
More completely:
Parameter names beginning with _pq_. are reserved for use *by* protocol extensions and are called protocol parameters, while others are run-time parameters to be set at backend start time.
And this, the second:
- libpq_ngettext("protocol extension not supported by server: %s",
- "protocol extensions not supported by server: %s", num),
+ libpq_ngettext("protocol option not supported by server: %s",
+ "protocol options not supported by server: %s", num),
To which I suggest we write:
"protocol parameter not supported by server: %s"
The backup usage noted here doesn't even seem to relate specifically to the frontend/backend protocol; or rather the protocol is designed so that the client and server can change their behavior without requiring the protocol layer to change. A message type is unrelated to a protocol parameter.
Thus I'd get rid of the word protocol altogether. Something like:
[This also allows]
for simpler enhancements to the backup process since the server can add new information
[in the message stream...]
Though a slightly more involved (i.e., multiple line) re-wording should be considered.
David J.
