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

From: Dave Cramer <davecramer(at)gmail(dot)com>
To: Heikki Linnakangas <hlinnaka(at)iki(dot)fi>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Jacob Champion <jacob(dot)champion(at)enterprisedb(dot)com>, Jelte Fennema-Nio <postgres(at)jeltef(dot)nl>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Jacob Burroughs <jburroughs(at)instructure(dot)com>, Peter Smith <smithpb2250(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "Andrey M(dot) Borodin" <x4mmm(at)yandex-team(dot)ru>, Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>, Jeff Davis <pgsql(at)j-davis(dot)com>, Peter Eisentraut <peter(at)eisentraut(dot)org>
Subject: Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs
Date: 2024-08-16 20:03:13
Message-ID: CADK3HHL1aZXoKKfr07wW80QAwLPLKC3WjBTAhSDH4fh=Wz8ivw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Fri, 16 Aug 2024 at 15:54, Heikki Linnakangas <hlinnaka(at)iki(dot)fi> wrote:

> On 16/08/2024 22:45, Dave Cramer wrote:
> > On Fri, 16 Aug 2024 at 15:26, Heikki Linnakangas <hlinnaka(at)iki(dot)fi
> > <mailto:hlinnaka(at)iki(dot)fi>> wrote:
> >
> > On 16/08/2024 21:01, Robert Haas wrote:
> > > On Fri, Aug 16, 2024 at 1:44 PM Jacob Champion
> > > <jacob(dot)champion(at)enterprisedb(dot)com
> > <mailto:jacob(dot)champion(at)enterprisedb(dot)com>> wrote:
> > >>
> >
> https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89
> <
> https://github.com/psycopg/psycopg2/blob/658afe4cd90d3e167d7c98d22824a8d6ec895b1c/tests/test_async.py#L89
> >
> > >>
> >
> https://github.com/infusion/PHP/blob/7ebefb6426bb4b4820a30cca5c3a10bfd757b6ea/ext/pgsql/pgsql.c#L864
> <
> 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 ?
>
> Sorry, I don't understand the question. This sub-thread is all about the
> libpq PQprotocolVersion() function.
>

Admittedly I'm a bit late into this discussion so I may be off base.
Ultimately we need to negotiate the protocol. From what I can tell for
libpq we are providing a function that returns a number, currently 3.

The proposal is to change it to something like 30000.

Ultimately this has to go over the wire so that clients that are
implementing the protocol themselves can respond to the new behaviour.

Wouldn't we have to send this number in the protocol negotiation ?

Dave

>
>

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2024-08-16 20:04:35 Re: pg_verifybackup: TAR format backup verification
Previous Message Heikki Linnakangas 2024-08-16 19:54:25 Re: Add new protocol message to change GUCs for usage with future protocol-only GUCs