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 | CAGECzQRbktH-VFDwe=Mw+Sp2sM0yF48XdYW-X4avTap_mB+XvA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs ("David G. Johnston" <david.g.johnston@gmail.com>) |
Список | pgsql-hackers |
On Tue, 20 Aug 2024 at 19:02, David G. Johnston <david.g.johnston@gmail.com> wrote: > So basically my proposal amounted to making every update a "major version update" and changing the behavior surroundingNegotiateProtocolVersion so it applies to major version differences. I'll stand by that change in definition. The current one doesn't seem all that useful anyway, and as we only have a single version, definitely hasn'tbeen materially implemented. Otherwise, at some point a client that knows both v3 and v4 will exist and its connectionwill be rejected instead of downgraded by a v3-only server even though such a downgrade would be possible. I suspectwe'd go ahead and change the rule then - so why not just do so now, while getting rid of the idea that minor versionsare a thing. If we decide to never change the format of the StartupMessage again (which may be an okay thing to decide). Then I agree it would make sense to update the existing supported servers ASAP to be able to send back a NegotiateProtocolVersion message if they receive a 4.x StartupMessage, and the server only supports up to 3.x. However, even if we do that, I don't think it makes sense to start using the 4.0 version straight away. Because many older postgres servers would still throw an error when receiving the 4.x request. By using a 3.x version we are able to avoid those errors in the existing ecosystem. Basically, I think we should probably wait ~5 years again until we actually use a 4.0 version. i.e. I don't see serious benefits to using 4.0. The main benefit you seem to describe is: "it's theoretically cleaner to use major version bumps". And there is a serious downside: "seriously breaking the existing ecosystem". > I suppose we could leave minor versions for patch releases of the main server version - which still leaves the first newfeature of a release incrementing the major version. That would be incidental to changing how we handle major versions. Having a Postgres server patch update change the protocol version that the server supports sounds pretty scary to me.
В списке pgsql-hackers по дате отправления: