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 1va4LG-003AsF-17 for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 03:54:47 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1va4LE-00FRX9-1T for pgsql-hackers@arkaria.postgresql.org; Mon, 29 Dec 2025 03:54:45 +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 1va4LE-00FRX1-0W for pgsql-hackers@lists.postgresql.org; Mon, 29 Dec 2025 03:54:44 +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 1va4LC-003L5N-1Z for pgsql-hackers@lists.postgresql.org; Mon, 29 Dec 2025 03:54: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 5BT3sWaH2744537; Sun, 28 Dec 2025 22:54:32 -0500 From: Tom Lane To: Michael Paquier cc: Erik Wienhold , zengman , pgsql-hackers Subject: Re: Regression with large XML data input In-reply-to: References: <586b74bb-8941-420f-82c4-ba93e5b42b20@ewie.name> <89bbd852-eea9-42e8-bab6-bb8df59685de@ewie.name> <1411819.1766685038@sss.pgh.pa.us> Comments: In-reply-to Michael Paquier message dated "Mon, 29 Dec 2025 09:24:29 +0900" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <2744535.1766980472.1@sss.pgh.pa.us> Date: Sun, 28 Dec 2025 22:54:32 -0500 Message-ID: <2744536.1766980472@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Michael Paquier writes: > On Thu, Dec 25, 2025 at 12:50:38PM -0500, Tom Lane wrote: >> That would be my preferred answer, but after a quick census of the >> buildfarm I'm not sure we can get away with it. The animals that >> are showing these warnings are all running RHEL 10 or clones of it, >> which is going to be in-support till 2035 or so. Maybe Red Hat >> will upgrade to a newer libxml2 version than whatever they chose >> for RHEL 10.0, but I would not count on it. > Hmm. Having to deal with these warnings until 2035 kind of sucks. Do > you think that it be worth forcing the use of > -Wno-deprecated-declarations only for versions older than 2.13.3 in > the Makefiles where we could see these warnings? It seems pretty painful to identify the libxml2 version during configure, do you have an idea how to do that? (And how about on the meson side?) > As a whole, this kind of enforcement gives me mixed feelings, because > it would also mean that we would miss what looks like legit > deprecation warnings that we had better look at and study, even for > LLVM. At least not enforcing any policy lets us know about these > issues. Right. I feel very itchy about adding -Wno-deprecated-declarations with no plan for getting rid of it again. Seeing that libxml2 seems to be a moving target again, it seems like that would eventually bite us on the rear. [ thinks... ] Actually, I believe we do have precedents in configure for checking to see if a construct produces a warning, so we could check to see if a reference to xmlKeepBlanksDefault draws one, and only add -Wno-deprecated-declarations if it does. But I'm not sure how to do that in meson. regards, tom lane