On Mon, Dec 23, 2024 at 8:39 AM Jelte Fennema-Nio <postg...@jeltef.nl>
wrote:
> On Thu, 31 Oct 2024 at 18:15, Jelte Fennema-Nio <postg...@jeltef.nl>
> wrote:
> >
> > On Thu, 31 Oct 2024 at 15:50, Heikki Linnakangas <hlinn...@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.
