postgres.git / summary / log / commit / refs

commit    85d799ba8a7fe3f6a462fcccbb449e08d21f4ea4
Author:   Heikki Linnakangas <heikki.linnakangas@iki.fi>
Date:     Wed Apr 02 12:32:33 2025 +0000

    docs: Update phrase on 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
    CopyData messags, even though it often still makes sense to have
    length fields for individual parts in messages.
    
    Discussion: https://www.postgresql.org/message-id/02a4eed2-98f0-4796-9d4f-12128ff44fe0@iki.fi


 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 04d8e7d21af..6008f3ac5f8 100644
--- a/doc/src/sgml/protocol.sgml
+++ b/doc/src/sgml/protocol.sgml
@@ -3624,10 +3624,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 for historical reasons, as the
+   original, now-obsolete protocol version 2 did not have an explicit length
+   field.  It also aids validity checking though.
   </para>
 
   <variablelist>


[parent: a6285b150ad3]