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 1wAVgI-0002f8-0K for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 16:23:06 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1wAVgG-000aRq-1Y for pgsql-hackers@arkaria.postgresql.org; Wed, 08 Apr 2026 16:23:05 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1wAVgG-000aRh-0d for pgsql-hackers@lists.postgresql.org; Wed, 08 Apr 2026 16:23:05 +0000 Received: from sss.pgh.pa.us ([68.162.161.243]) by makus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wAVgF-000000001It-0QsM for pgsql-hackers@postgresql.org; Wed, 08 Apr 2026 16:23:04 +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 638GN1TM3070728; Wed, 8 Apr 2026 12:23:01 -0400 From: Tom Lane To: Nathan Bossart cc: pgsql-hackers@postgresql.org Subject: Re: bump minimum supported version of psql and pg_{dump,dumpall,upgrade} to v10 In-reply-to: References: Comments: In-reply-to Nathan Bossart message dated "Wed, 08 Apr 2026 10:47:27 -0500" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <3070726.1775665381.1@sss.pgh.pa.us> Date: Wed, 08 Apr 2026 12:23:01 -0400 Message-ID: <3070727.1775665381@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > I've brought this up a couple times in the past ~year, so here's a patch. > Supporting versions as old as v9.2 has become quite cumbersome, requiring > various version-specific branches and hacks. I believe our current policy > is that we support at least 10 previous major versions [0]. For reference, > we last bumped the minimum to v9.2 in 2021 (commits 30e7c175b 81, > e469f0aaf3, and cf0cab868a). I'm on board with this for v20, but as a matter of reviewing the patch: it'd be easier if you separated it into two steps, one that does the actual changes but doesn't reindent anything, and then a separate application of pgindent. As this diff stands, there's an awful lot of noise resulting from outdenting no-longer-conditional code, which has to be reviewed by hand but it could be checked mechanically if you left it to a "this just applies pgindent" step. Looking at the commit log, I was struck by my comment in 30e7c175b: (As in previous changes of this sort, we aren't removing pg_restore's ability to read older archive files ... though it's fair to wonder how that might be tested nowadays.) I wonder whether we ought to sunset some of that code too, and if so how to draw the line on minimum archive version to support. BTW, see also 492046fa9. regards, tom lane