Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
David G. Johnston <david.g.johnston@gmail.com>
From: "David G. Johnston" <david.g.johnston@gmail.com>
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Heikki Linnakangas <hlinnaka@iki.fi>,
Jelte Fennema-Nio <postgres@jeltef.nl>, Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.com>,
Dave Cramer <davecramer@gmail.com>, Peter Smith <smithpb2250@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>,
Pavel Stehule <pavel.stehule@gmail.com>, Jeff Davis <pgsql@j-davis.com>, Peter Eisentraut <peter@eisentraut.org>, Daniele Varrazzo <daniele.varrazzo@gmail.com>
Date: 2024-08-20T17:55:46Z
Lists: pgsql-hackers
Commits
Same data as JSON:
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
libpq: Add min/max_protocol_version connection options
- 285613c60a7a 18.0 landed
-
libpq: Handle NegotiateProtocolVersion message differently
- 5070349102af 18.0 landed
-
Add PQfullProtocolVersion() to surface the precise protocol version.
- cdb6b0fdb0b2 18.0 landed
-
Do not hardcode PG_PROTOCOL_LATEST in NegotiateProtocolVersion
- 516b87502dc1 18.0 landed
-
libpq: Handle NegotiateProtocolVersion message
- bbf9c282ce92 16.0 cited
-
Provide for forward compatibility with future minor protocol versions.
- ae65f6066dc3 11.0 cited
On Tue, Aug 20, 2024 at 10:46 AM Jacob Champion < jacob.champion@enterprisedb.com> wrote: > On Tue, Aug 20, 2024 at 10:42 AM David G. Johnston > <david.g.johnston@gmail.com> wrote: > > Semantic versioning guidelines are not something we are following, > especially here. > > I understand; the protocol is ours, and we'll do whatever we do in the > end. I'm claiming that we can choose to provide semantics, and if we > do, those semantics will help people who are not here on the list to > defend their use cases. > > I was mostly just responding to your surprise given that we have a track-record here. I agree that our existing effective policy isn't all that well documented, namely as to when the major component might change, and the fact that the minor component does not represent a "bug fix release". David J.