From: | Heikki Linnakangas <hlinnaka(at)iki(dot)fi> |
---|---|
To: | Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Use "protocol options" name instead of "protocol extensions" everywhere |
Date: | 2024-10-31 14:50:53 |
Message-ID: | c70ddf38-221a-473d-9872-c0326f1c7dd6@iki.fi |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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)
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-10-31 15:05:41 | Re: make all ereport in gram.y print out relative location |
Previous Message | Bertrand Drouvot | 2024-10-31 14:26:57 | Re: Proper object locking for GRANT/REVOKE |