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

Dave Cramer <davecramer@gmail.com>

From: Dave Cramer <davecramer@gmail.com>

To: Heikki Linnakangas <hlinnaka@iki.fi>

Cc: Robert Haas <robertmhaas@gmail.com>, Jacob Champion <jacob.champion@enterprisedb.com>, Jelte Fennema-Nio <postgres@jeltef.nl>, Tom Lane <tgl@sss.pgh.pa.us>, Jacob Burroughs <jburroughs@instructure.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-08-16T19:45:14Z

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, 16 Aug 2024 at 15:26, Heikki Linnakangas <hlinnaka@iki.fi> wrote:

> On 16/08/2024 21:01, Robert Haas wrote:
> > On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion
> > <jacob.champion@enterprisedb.com> wrote:
> >>
> https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89
> >>
> https://github.com/infusion/PHP/blob/7ebefb6426bb4b4820a30cca5c3a10bfd757b6ea/ext/pgsql/pgsql.c#L864
> >
> > IMHO these examples establish beyond doubt that the existing function
> > really is being used in ways that would break if we committed the
> > proposed patch. To be honest, I'm slightly surprised, because protocol
> > version 2 has been so dead for so long that I would not have
> > anticipated people would even bother checking for it. But these
> > examples show that some people do. If Jacob found these examples this
> > easily, there are probably a bunch of others.
> >
> > It's not worth breaking existing code to avoid adding one new libpq
> > entrypoint. Let's just add the new function and move on.
>
> +1. Jacob is right.
>

For those of us who don't use a function. How will this work ?

Dave