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 1ubobU-005cZ6-7W for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jul 2025 22:58:28 +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 1ubobS-006408-Bq for pgsql-hackers@arkaria.postgresql.org; Tue, 15 Jul 2025 22:58:27 +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.94.2) (envelope-from ) id 1ubobS-006400-2G for pgsql-hackers@lists.postgresql.org; Tue, 15 Jul 2025 22:58:26 +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 1ubobQ-007xHt-1n for pgsql-hackers@postgresql.org; Tue, 15 Jul 2025 22:58: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 56FMwALr1138044; Tue, 15 Jul 2025 18:58:10 -0400 From: Tom Lane To: Peter Geoghegan cc: Andres Freund , Dmitry Mityugov , pgsql-hackers@postgresql.org Subject: Re: patch: Use pg_assume in jsonb_util.c to fix GCC 15 warnings In-reply-to: References: <0c623e8a204187b87b4736792398eaf1@postgrespro.ru> <82868.1752342174@sss.pgh.pa.us> Comments: In-reply-to Peter Geoghegan message dated "Tue, 15 Jul 2025 18:35:01 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <1138042.1752620290.1@sss.pgh.pa.us> Date: Tue, 15 Jul 2025 18:58:10 -0400 Message-ID: <1138043.1752620290@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Peter Geoghegan writes: > In the past, it was often necessary to work around MSVC's inability to > see that a block containing elog(ERROR) doesn't actually need to > initialize variables that'll never actually be used in code that comes > after that block. We still have many "keep compiler quiet" variable > initializations due to this. > Is that still something that we need to worry about? Good question. It's not very clear what set of compiler versions people are still using, but maybe it'd be okay to stop worrying about suppressing such warnings. regards, tom lane