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.
From a06619bcd5c85b6f38cb6a3d03c2a4e6ffbb9b53 Mon Sep 17 00:00:00 2001
From: Jelte Fennema-Nio <github-t...@jeltef.nl>
Date: Wed, 30 Oct 2024 14:37:00 +0100
Subject: [PATCH v1] Rename protocol extensions to protocol options in docs
Currently we call connection parameters that have the "_pq_." prefix
both "protocol options" and "protocol extensions". This standardizes on
calling them "protocol options". The primary reason to do this is so
people don't associate them with Postgres extensions, with which they
have nothing to do. They are completely separate things, and Postgres
extensions currently cannot even define their own protocol options.
---
doc/src/sgml/protocol.sgml | 2 +-
src/backend/backup/basebackup_copy.c | 2 +-
src/interfaces/libpq/fe-protocol3.c | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 71b6b2a535..fc1255b7eb 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -5941,7 +5941,7 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
In addition to the above, other parameters may be listed.
Parameter names beginning with <literal>_pq_.</literal> are
- reserved for use as protocol extensions, while others are
+ reserved for use as protocol options, while others are
treated as run-time parameters to be set at backend start
time. Such settings will be applied during backend start
(after parsing the command-line arguments if any) and will
diff --git a/src/backend/backup/basebackup_copy.c b/src/backend/backup/basebackup_copy.c
index 0b4ee5f2a2..8cfcae47ad 100644
--- a/src/backend/backup/basebackup_copy.c
+++ b/src/backend/backup/basebackup_copy.c
@@ -9,7 +9,7 @@
* the course of that single COPY OUT. Each CopyData message begins with a
* type byte, allowing us to signal the start of a new archive, or the
* manifest, by some means other than ending the COPY stream. This also allows
- * for future protocol extensions, since we can include arbitrary information
+ * for future protocol options, since we can include arbitrary information
* in the message stream as long as we're certain that the client will know
* what to do with it.
*
diff --git a/src/interfaces/libpq/fe-protocol3.c b/src/interfaces/libpq/fe-protocol3.c
index 8c5ac1729f..a84ea7a786 100644
--- a/src/interfaces/libpq/fe-protocol3.c
+++ b/src/interfaces/libpq/fe-protocol3.c
@@ -1439,8 +1439,8 @@ pqGetNegotiateProtocolVersion3(PGconn *conn)
if (num > 0)
{
appendPQExpBuffer(&conn->errorMessage,
- 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),
buf.data);
appendPQExpBufferChar(&conn->errorMessage, '\n');
}
--
2.43.0
