MIME-Version: 1.0
References: <CADK3HHKe1PA1U6aB5-7tWBQ0yZGgNvY7H=ECDD9955Pas_zx_Q@mail.gmail.com>
 <CAGECzQRQ5optaG4DPbshKS+zpUtn_oceh8-qdshFbS+-FSb8Dg@mail.gmail.com>
 <CAOYmi+nVQRpSs3vd_v9L8ytO9wnL2ndnzGwU31aDGorVFxrAYA@mail.gmail.com>
 <CAGECzQSZ43JMjA8QEJoF9DCdTO0GQeR2qyhouQciSG2ik40Yhg@mail.gmail.com>
 <CAOYmi+m20jS8zZ2qFpSnvhaqGDX+vtgCsqcu9VhokyLqF8kFag@mail.gmail.com>
 <CADK3HH+DPY_x_H=e0c_AVWoUP9E+YXdyJDVvmzYEYxZXT87Agw@mail.gmail.com>
 <CAGECzQRZwbuSNp-mgPWmC97q63ODAun=pQtXa1Ru19ksz986Hg@mail.gmail.com>
 <CADK3HHKDrnRAoAcUv1ucLB0o_ZUcJRwm+jonNPNUHoDtcA9Crw@mail.gmail.com>
 <CAGECzQQriv-h_h8Ygxh_RfnLt2G4P9nWrpgMi9YL2bmcOLbUEA@mail.gmail.com>
 <CADK3HHL_cUzm-R+0nHcLvxdOZQeR0YKQMDjwLTEiGX-F9=tbeA@mail.gmail.com>
 <CADK3HH+o9dTYsXpCk7-Z0JW-QB2TV7=e97O8B-XDOGQb14AfSQ@mail.gmail.com>
 <CAOYmi+kkTbuwGa9X=XomNivAw9P4hN3M1U7QXiP7Jw+nrQXtNQ@mail.gmail.com>
 <CAGECzQSfCPXdOpUKfdkPA9iZhGyRjZAad-CXbhApZ2CnjgG2kw@mail.gmail.com> <CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com>
In-Reply-To: <CAOYmi+=qE1khrtTD7oQVPJQTHoXffQQ0DPHOx870r7801zhw9g@mail.gmail.com>
From: Jelte Fennema-Nio <postgres@jeltef.nl>
Date: Thu, 8 Jan 2026 08:38:28 +0100
Message-ID: <CAGECzQTVsLcLz=utq5WoihADF-7LXLn6+EeV4oxdjOpW-w_poA@mail.gmail.com>
Subject: Re: Proposal to allow setting cursor options on Portals
To: Jacob Champion <jacob.champion@enterprisedb.com>
Cc: Dave Cramer <davecramer@gmail.com>, 
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>, Heikki Linnakangas <hlinnaka@iki.fi>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://www.postgresql.org/message-id/CAGECzQTVsLcLz%3Dutq5WoihADF-7LXLn6%2BEeV4oxdjOpW-w_poA%40mail.gmail.com>
Precedence: bulk

On Thu, 8 Jan 2026 at 01:39, Jacob Champion
<jacob.champion@enterprisedb.com> wrote:
> > Having a single version is only 1 option,
>
> Seems like clients must support 3.0 up to 3.N in practice, and test
> all of those. If you want a feature in 3.6 and the server says it only
> supports 3.4, you're speaking 3.4 now. That's still N options.

I meant 1 per yearly set of protocol features. So if there's M years
with protocol features and on average N features per each of those
years the amount of different options to consider over time are:
For only version bumps: M
For completely orthogonal protocol extensions: M*N
For completely non-orthogonal options: (M*N)^2

> You're saying "well hopefully clients don't actually have to support
> all of them," but I don't think you gave a reason why that would be
> okay for a production implementation.

Clients don't have to care about every postgres version that ever
existed, or every possible proxy in existence. In 5 years, a client
author might just say: well I only care about my client being able to
connect to supported postgres servers, so if a server downgrades to
protocol 3.0 I close the connection.

This is a decision for the client author to make and for the client
author only. And they don't need to care about any of the other
clients in existence at all. Only the servers their client should be
able to connect to.

> Is there an unstated assumption
> here, that we'll eventually drop support for 3.0 at some point
> relatively soon? (And then 3.2, and then...) If so, I'd prefer to
> focus the conversation on that assumption. Because that seems like a
> complete nonstarter to me, personally.

No, that's not what I meant. Because postgres has to care about the
clients it wants to support. And that's all of them. There will
probably be clients supporting only 3.0 for a very long time. So the
postgres server will need to be supporting 3.0 for a very long time.