Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdg7Y-003PAg-2c for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jan 2026 02:51:33 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vdg7W-00H0yp-2q for pgsql-hackers@arkaria.postgresql.org; Thu, 08 Jan 2026 02:51:31 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdg7W-00H0yh-1r for pgsql-hackers@lists.postgresql.org; Thu, 08 Jan 2026 02:51:31 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1vdg7U-005CEq-2N for pgsql-hackers@lists.postgresql.org; Thu, 08 Jan 2026 02:51:30 +0000 Received: from sss1.sss.pgh.pa.us (localhost [127.0.0.1]) by sss.pgh.pa.us (8.15.2/8.15.2) with ESMTP id 6082p4l31884349; Wed, 7 Jan 2026 21:51:04 -0500 From: Tom Lane To: Jacob Champion cc: Jelte Fennema-Nio , Dave Cramer , PostgreSQL Hackers , Heikki Linnakangas Subject: Re: Proposal to allow setting cursor options on Portals In-reply-to: References: Comments: In-reply-to Jacob Champion message dated "Wed, 07 Jan 2026 16:39:33 -0800" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1884347.1767840664.1@sss.pgh.pa.us> Date: Wed, 07 Jan 2026 21:51:04 -0500 Message-ID: <1884348.1767840664@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Jacob Champion writes: > 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. 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. After we introduced protocol version 3.0, it took us 18 years to drop support for version 2 (2003..2021). We introduced 3.2 in 2025, so on the same schedule we won't drop 3.0 support before 2043. If anyone's thinking that it can happen significantly faster this time around, I'm here to disabuse you of that notion. Considering how much larger the Postgres ecosystem is now than it was in 2003, it will probably take *longer* for everything to be sufficiently on-board for another hard break. I'm pretty bemused by this entire discussion. We have a perfectly good design for handling new protocol features without any hard protocol break, so I don't understand why people are insisting on doing things incompatibly when they could be doing them compatibly. I quote from Robert's commit ae65f6066 (the same one that invented NegotiateProtocolVersion): In addition, if the startup packet includes name/value pairs where the name starts with "_pq_.", assume that those are protocol options, not GUCs. Include those we don't support (i.e. all of them, at present) in the NegotiateProtocolVersion message so that the client knows they were not understood. This makes it possible for the client to request previously-unsupported features without bumping the protocol version at all; the client can tell from the server's response whether the option was understood. I think that the right way forward is that the protocol version stays at 3.2 for several decades more, and we implement requests for individual protocol-level features through the "_pq_." mechanism. I would not have any use for 3.2 as such at all, except that asking for that is needed to ensure that the server knows about NegotiateProtocolVersion. regards, tom lane