Re: Use "protocol options" name instead of "protocol extensions" everywhere

On Mon, 2024-12-23 at 16:39 +0100, Jelte Fennema-Nio wrote:
> 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)

My vote is to stick with "extension".

In the protocol documentation [1], right before the place where the
proposed patch wants to change "extensions" to "options", "option" is
used for command line arguments for the backend.  Elsewhere, we use
"options" for parenthesized lists like "ANALYZE (option, ...) ..." or
"CREATE FOREIGN TABLE ... OPTIONS (...)".

I think that there is less potential for confusion with "extension".
To me, a "protocol extension" would be something that adds new
features to a protocol, while a "protocol option" sounds like a
switch that has always been there.

Yours,
Laurenz Albe


 [1]: https://www.postgresql.org/docs/17/protocol-message-formats.html#PROTOCOL-MESSAGE-FORMATS-STARTUPMESSAGE