Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbofF-00061F-6d for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Apr 2022 19:16:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1nbofD-0005RW-GS for pgsql-hackers@arkaria.postgresql.org; Tue, 05 Apr 2022 19:16:27 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbofD-0005RN-7J for pgsql-hackers@lists.postgresql.org; Tue, 05 Apr 2022 19:16:27 +0000 Received: from sss.pgh.pa.us ([66.207.139.130]) by magus.postgresql.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nbofA-000549-HT for pgsql-hackers@postgresql.org; Tue, 05 Apr 2022 19:16:26 +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 235JGKQL2661154; Tue, 5 Apr 2022 15:16:20 -0400 From: Tom Lane To: Robert Haas cc: Markus Wanner , "pgsql-hackers@postgresql.org" , Kyotaro Horiguchi Subject: Re: API stability [was: pgsql: Fix possible recovery trouble if TRUNCATE overlaps a checkpoint.] In-reply-to: References: <2358496.1649168259@sss.pgh.pa.us> <2360280.1649169126@sss.pgh.pa.us> Comments: In-reply-to Robert Haas message dated "Tue, 05 Apr 2022 10:51:01 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2661152.1649186180.1@sss.pgh.pa.us> Date: Tue, 05 Apr 2022 15:16:20 -0400 Message-ID: <2661153.1649186180@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Robert Haas writes: > On Tue, Apr 5, 2022 at 10:32 AM Tom Lane wrote: >> My point is that we want that to happen in HEAD, but it's not okay >> for it to happen in a minor release of a stable branch. > I understand, but I am not sure that I agree. I think that if an > extension stops compiling against a back-branch, someone will notice > the next time they try to compile it and will fix it. Maybe that's not > amazing, but I don't think it's a huge deal either. Well, perhaps it's not the end of the world, but it's still a large PITA for the maintainer of such an extension. They can't "just fix it" because some percentage of their userbase will still need to compile against older minor releases. Nor have you provided any way to handle that requirement via conditional compilation. regards, tom lane