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: Tom Lane <tgl@sss.pgh.pa.us>, Jelte Fennema-Nio <me@jeltef.nl>

Cc: PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, 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-29T19:14: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 Fri, 2023-12-29 at 13:38 -0500, Tom Lane wrote:
> > 2. It paves the way for GUCs that can only be set using a protocol
> > message (and not using SET).
> 
> This is assuming facts not in evidence.  Why would we want such a
> thing?

The problem came up during the binary_formats GUC discussion: it
doesn't really make sense to change that with a SQL query, and doing so
can cause strange things to happen.

We already have the issue with client_encoding and binary format COPY,
so arguably it's not worth trying to solve it. But protocol-only GUCs
was one idea that came up.

Regards,
	Jeff Davis