Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs

Jeff Davis <pgsql@j-davis.com>

From: Jeff Davis <pgsql@j-davis.com>

To: Jelte Fennema-Nio <me@jeltef.nl>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Cc: Dave Cramer <davecramer@gmail.com>, Robert Haas <robertmhaas@gmail.com>, Jacob Burroughs <jburroughs@instructure.com>, "Andrey M. Borodin" <x4mmm@yandex-team.ru>, Pavel Stehule <pavel.stehule@gmail.com>, Peter Eisentraut <peter@eisentraut.org>

Date: 2023-12-29T18:32:15Z

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 Fri, 2023-12-29 at 18:29 +0100, Jelte Fennema-Nio wrote:
> 2. It paves the way for GUCs that can only be set using a protocol
> message (and not using SET).

That sounds useful for GUCs that can interfere with the client, such as
client_encoding or the proposed GUC in you referred to at [1].

> There's definitely still some more work that needs to be done
> (docs for new libpq APIs, protocol version bump, working protocol
> version negotiation).

That is my biggest concern right now: what will new clients connecting
to old servers do?

If the version is bumped, should we look around for other unrelated
protocol changes to make at the same time? Do we want a more generic
form of negotiation?

Regards,
	Jeff Davis