From: | Tatsuo Ishii <ishii(at)postgresql(dot)org> |
---|---|
To: | david(dot)g(dot)johnston(at)gmail(dot)com |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: NegotiateProtocolVersion description |
Date: | 2025-07-05 22:07:53 |
Message-ID: | 20250706.070753.2006294786940689439.ishii@postgresql.org |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> Add an example? I like the wording as-is, though I can see your point. I
> wouldn’t expect the returned value to be a fragment of a version in this
> context so minor just emphasizes that the client is applying a filter on
> the major version it supports. I’d be ok with removing “minor” altogether.
Probably not necessary to remove "minor". It seems our document
consistently uses "minor protocol version" to mean the whole protocol
version, not a fragment.
Followings are my understanding;
major version (number):
The most significant 16 bits of the protocol version (i.e. 3)
minor version (number):
The least significant 16 bits of the protocol version (i.e. 2)
major protocol version:
The major version part of the protocol version. Only used in
NegotiateProtocolVersion.
minor protocol version:
The whole protocol version including minor version (3.2)
Best regards,
--
Tatsuo Ishii
SRA OSS K.K.
English: http://www.sraoss.co.jp/index_en/
Japanese:http://www.sraoss.co.jp
From | Date | Subject | |
---|---|---|---|
Next Message | Tatsuo Ishii | 2025-07-05 22:08:38 | Re: NegotiateProtocolVersion description |
Previous Message | Arseniy Mukhin | 2025-07-05 20:19:35 | Re: amcheck support for BRIN indexes |