Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
От | Jelte Fennema-Nio |
---|---|
Тема | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs |
Дата | |
Msg-id | CAGECzQT8L4q6WVYNCyqds+9G3iMqq9yFpbEbbdCde=kvWACavw@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs (Jacob Champion <jacob.champion@enterprisedb.com>) |
Список | pgsql-hackers |
On Tue, 23 Apr 2024 at 19:39, Jacob Champion <jacob.champion@enterprisedb.com> wrote: > > On Mon, Apr 22, 2024 at 2:20 PM Jelte Fennema-Nio <me@jeltef.nl> wrote: > > 1. I strongly believe minor protocol version bumps after the initial > > 3.1 one can be made painless for clients/poolers (so the ones to > > 3.2/3.3/etc). Similar to how TLS 1.3 can be safely introduced, and not > > having to worry about breaking TLS 1.2 communication. > > Apologies for focusing on a single portion of your argument, but this > claim in particular stuck out to me. To my understanding, IETF worried > a _lot_ about breaking TLS 1.2 implementations with the TLS 1.3 > change, to the point that TLS 1.3 clients and servers advertise > themselves as TLS 1.2 and sneak the actual version used into a TLS > extension (roughly analogous to the _pq_ stuff). I vaguely recall that > the engineering work done for that update was pretty far from > painless. My bad... I guess TLS 1.3 was a bad example, due to it changing the handshake itself so significantly.
В списке pgsql-hackers по дате отправления: