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 по дате отправления:

Предыдущее
От: Jelte Fennema-Nio
Дата:
Сообщение: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Следующее
От: Robert Haas
Дата:
Сообщение: Re: Removing unneeded self joins