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 1vQZjR-00Bi7X-0m for pgsql-bugs@arkaria.postgresql.org; Tue, 02 Dec 2025 23:24:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.96) (envelope-from ) id 1vQZjQ-00ATDY-0B for pgsql-bugs@arkaria.postgresql.org; Tue, 02 Dec 2025 23:24:28 +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 1vQZjP-00ATDQ-2Y for pgsql-bugs@lists.postgresql.org; Tue, 02 Dec 2025 23:24:28 +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 1vQZjO-002oqh-0V for pgsql-bugs@lists.postgresql.org; Tue, 02 Dec 2025 23:24:27 +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 5B2NOKkl513346; Tue, 2 Dec 2025 18:24:20 -0500 From: Tom Lane To: Dean Rasheed cc: Oleg Ivanov , Laurenz Albe , pgsql-bugs@lists.postgresql.org Subject: Re: BUG #19340: Wrong result from CORR() function In-reply-to: References: <19340-6fb9f6637f562092@postgresql.org> <4ab9867066e9545dd1a7e835a480bb0ecbe1a00d.camel@cybertec.at> <375068.1764696127@sss.pgh.pa.us> <434484.1764707203@sss.pgh.pa.us> Comments: In-reply-to Dean Rasheed message dated "Tue, 02 Dec 2025 23:03:45 +0000" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <513344.1764717860.1@sss.pgh.pa.us> Date: Tue, 02 Dec 2025 18:24:20 -0500 Message-ID: <513345.1764717860@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk Dean Rasheed writes: > I played around with having just 2 extra array elements, constX and > constY equal to the common value if all the values are the same, and > NaN otherwise. Hmm. > Doing it that way does lead to one difference though: all-NaN inputs > leads to a NaN result, whereas your patch produces NULL for that case. Yeah, I did it as I did precisely because I wanted all-NaN-input to be seen as a constant. But you could make an argument that NaN is not really a fixed value but has more kinship to the "we don't know what the value is" interpretation of SQL NULL. In that case your proposal is semantically reasonable on the grounds that maybe the NaNs aren't really all equal, and I agree it ought to be a little faster than mine. regards, tom lane