Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Jelte Fennema-Nio <me@jeltef.nl>,
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>
Date: 2024-05-23T19:45:26Z
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 Thu, May 23, 2024 at 2:12 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > I got around to looking through this thread in preparation for next > week's patch review session. I have a couple of opinions to offer: I agree with these opinions. Independently of that, I'm glad you shared them. I think part of the reason we ended up with the protocol parameters = GUCs thing is because you seemed to be concurring with that approach upthread. I think it was Jelte's idea originally, but I interpreted some of your earlier remarks to be supporting it. I'm not sure whether you've revised your opinion, or just refined it, or whether we misinterpreted your earlier remarks. -- Robert Haas EDB: http://www.enterprisedb.com