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.94.2) (envelope-from ) id 1r5IxH-00Ct6C-7v for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Nov 2023 05:05:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1r5IxF-00D4S1-Nz for pgsql-hackers@arkaria.postgresql.org; Tue, 21 Nov 2023 05:05:45 +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.94.2) (envelope-from ) id 1r5IxF-00D4Ro-Ed for pgsql-hackers@lists.postgresql.org; Tue, 21 Nov 2023 05:05:45 +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.94.2) (envelope-from ) id 1r5Ix8-006aZt-QL for pgsql-hackers@lists.postgresql.org; Tue, 21 Nov 2023 05:05:44 +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 3AL55a1v1425716; Tue, 21 Nov 2023 00:05:36 -0500 From: Tom Lane To: Nathan Bossart cc: Bharath Rupireddy , PostgreSQL Hackers Subject: Re: Do away with a few backwards compatibility macros In-reply-to: <20231121045840.GD3521465@nathanxps13> References: <20231116154622.GA2881373@nathanxps13> <20231121045840.GD3521465@nathanxps13> Comments: In-reply-to Nathan Bossart message dated "Mon, 20 Nov 2023 22:58:40 -0600" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1425714.1700543136.1@sss.pgh.pa.us> Date: Tue, 21 Nov 2023 00:05:36 -0500 Message-ID: <1425715.1700543136@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Nathan Bossart writes: > On Thu, Nov 16, 2023 at 09:46:22AM -0600, Nathan Bossart wrote: >> I'm fine with this because all of these macros are no-ops for all supported >> versions of Postgres. Even if an extension is using them today, you'll get >> the same behavior as before if you remove the uses and rebuild against >> v12-v16. > Barring objections, I'll plan on committing this in the next week or so. No objection here, but should we try to establish some sort of project policy around this sort of change (ie, removal of backwards-compatibility support)? "Once it no longer matters for any supported version" sounds about right to me, but maybe somebody has an argument for thinking about it differently. regards, tom lane