From 6060971265adccdb61b0c2b693f977cc404e93c8 Mon Sep 17 00:00:00 2001 From: Heikki Linnakangas 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 & 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. -- 2.39.5