0006-docs-Update-phrase-that-talks-about-message-lengths-.patch

From 6060971265adccdb61b0c2b693f977cc404e93c8 Mon Sep 17 00:00:00 2001
From: Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date: Tue, 1 Apr 2025 14:47:55 +0300
Subject: [PATCH 6/7] docs: Update phrase that talks about message lengths in
 the protocol

The reasoning for why all the message formats are parseable without
the explicit message length field is anachronistic; the real reason is
that protocol version 2 did not have a message length field. There's
nothing wrong with relying on the message length, like we do in the
new variable-length definitions of CancelRequest and BackendKeyData.,
even though it often still makes sense to have length fields for
individual parts in messages.
---
 doc/src/sgml/protocol.sgml | 8 ++++----
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/doc/src/sgml/protocol.sgml b/doc/src/sgml/protocol.sgml
index 1410b4984f2..8074085eec5 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -3650,10 +3650,10 @@ psql "dbname=postgres replication=database" -c "IDENTIFY_SYSTEM;"
    indicate that it can be sent by a frontend (F), a backend (B), or both
    (F &amp; B).
    Notice that although each message includes a byte count at the beginning,
-   the message format is defined so that the message end can be found without
-   reference to the byte count.  This aids validity checking.  (The CopyData
-   message is an exception, because it forms part of a data stream; the contents
-   of any individual CopyData message cannot be interpretable on their own.)
+   most messages are defined so that the message end can be found without
+   reference to the byte count.  This is mostly for historical reasons, as
+   the original, now-obsolete protocol version 2 did not have an explicit length
+   field, but it also aids validity checking.
   </para>
 
   <variablelist>
-- 
2.39.5