Thread: Re: Use "protocol options" name instead of "protocol extensions" everywhere
Re: Use "protocol options" name instead of "protocol extensions" everywhere
From
Heikki Linnakangas
Date:
On 30/10/2024 15:58, Jelte Fennema-Nio wrote: > It was pointed out by Heikki in the thread around protocol-level > wait-for-LSN that "protocol extensions" is a pretty confusing name, > since it suggests a relation to Postgres extensions. Even though there > is no such relationship at all. Attached is a small patch that aligns > on the name "protocol options" instead. This terminology is already > used in a bunch of the docs. > > Since no protocol options have been introduced yet, it seems like now > is a good time to align on what to call them. It might even be worth > backporting this to have our docs of previous versions be consistent. Bikeshedding time: "protocol option" makes me think of GUCs. "optional protocol features" perhaps. A bit long though.. Or keep using "protocol extension" and add a paragraph to the docs to say explicitly that there's no support for extensions to create protocol extensions. TLS extensions is a good comparison. I don't have a strong opinion, all of those would work for me. -- Heikki Linnakangas Neon (https://neon.tech)
On Thu, Oct 31, 2024 at 10:51 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Bikeshedding time: > > "protocol option" makes me think of GUCs. > > "optional protocol features" perhaps. A bit long though.. > > Or keep using "protocol extension" and add a paragraph to the docs to > say explicitly that there's no support for extensions to create protocol > extensions. TLS extensions is a good comparison. > > I don't have a strong opinion, all of those would work for me. I don't particularly like "optional protocol features". I find "protocol extensions" to be mildly clearer than "protocol options," but only mildly. I don't think it's really viable to promise that we'll never talk about extending anything other than in the context of what CREATE EXTENSION does. -- Robert Haas EDB: http://www.enterprisedb.com
Re: Use "protocol options" name instead of "protocol extensions" everywhere
From
Jacob Champion
Date:
On Thu, Oct 31, 2024 at 7:51 AM Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Or keep using "protocol extension" and add a paragraph to the docs to > say explicitly that there's no support for extensions to create protocol > extensions. TLS extensions is a good comparison. Of the three proposed, this last one is my preference. I think it'd be good to draw very clear lines between the transport level, the protocol level, and the application level. Thanks, --Jacob
Re: Use "protocol options" name instead of "protocol extensions" everywhere
From
Jelte Fennema-Nio
Date:
On Thu, 31 Oct 2024 at 15:50, Heikki Linnakangas <hlinnaka@iki.fi> wrote: > Bikeshedding time: Another few options: 4. Protocol enhancement 5. Protocol flag 6. Protocol feature-flag 7. Protocol configuration 8. Protocol parameter One thing to consider is that there's two ways of using them: 1. Turning an optional protocol feature on/of (send LSN yes/no) 2. Configuring an optional protocol feature (compress with gzip/lz4/zstd) I think "protocol extension" is a good name for the first. But it reads/writes a bit awkward for the second usage imo:. 1. The wait_for_lsn protocol extension needs to be enabled. 2. I configured the compression protocol extension to be gzip. I like that "protocol option" because it works for both: 1. The wait_for_lsn protocol option needs to be enabled. 2. I set the compression protocol option to gzip. I still think of these "protocol xyzs" as essentially being GUCs for the protocol. Especially because they are configured the same way as GUCs in the StartupMessage. So having "protocol option" making you think of GUCs doesn't necessarily seem like a bad thing to me.
Re: Use "protocol options" name instead of "protocol extensions" everywhere
From
Jelte Fennema-Nio
Date:
On Thu, 31 Oct 2024 at 17:09, Robert Haas <robertmhaas@gmail.com> wrote: > I don't think it's really viable to promise that we'll never talk > about extending anything other than in the context of what CREATE > EXTENSION does. Agreed, but it seems nice to avoid confusion by not overloading terminology, if we can find a good/decent alternative. When we do have an overloaded term, we should definitely document what we mean with it and how it differs from other usage of the term. But even then many people won't have read those docs and assume it means the thing that they expect it to mean. A good example of this is the fact that initdb creates a "database cluster". We definitely document that we use the term that way. But if you talk/write about a database cluster many people (understandably) expect you to mean a very different thing.