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 1jwuOG-00042t-4e for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Jul 2020 21:29:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.92) (envelope-from ) id 1jwuOE-0000de-Vu for pgsql-hackers@arkaria.postgresql.org; Sat, 18 Jul 2020 21:29:02 +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 1jwuOE-0000dX-Pa for pgsql-hackers@lists.postgresql.org; Sat, 18 Jul 2020 21:29:02 +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 1jwuO8-0007S3-7E for pgsql-hackers@lists.postgresql.org; Sat, 18 Jul 2020 21:29:02 +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 06ILSqnK4166231; Sat, 18 Jul 2020 17:28:53 -0400 From: Tom Lane To: Dean Rasheed cc: PostgreSQL Hackers Subject: Re: Wrong results from in_range() tests with infinite offset In-reply-to: <3941233.1595081173@sss.pgh.pa.us> References: <3393130.1594925893@sss.pgh.pa.us> <3464257.1594936216@sss.pgh.pa.us> <3506768.1594947597@sss.pgh.pa.us> <3941233.1595081173@sss.pgh.pa.us> Comments: In-reply-to Tom Lane message dated "Sat, 18 Jul 2020 10:06:13 -0400" MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <4166229.1595107732.1@sss.pgh.pa.us> Date: Sat, 18 Jul 2020 17:28:52 -0400 Message-ID: <4166230.1595107732@sss.pgh.pa.us> List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk I wrote: > Dean Rasheed writes: >> if (isinf(base) && isinf(offset)) >> { >> if ((base > 0 && sub) || (base < 0 && !sub)) >> PG_RETURN_BOOL(true); >> } > Yeah, I'd experimented with more-or-less that logic before arriving at > my v2 patch. I didn't like the outcome that "inf both infinitely precedes > and infinitely follows itself". Still, it is nicely simple. I spent some more time thinking about this, and came to a couple of conclusions. First, let's take it as given that we should only special-case situations where the sum would be computed as NaN. That destroys my position that, for instance, -inf shouldn't be included in the range that ends 'inf preceding' itself, because the normal calculation goes through as -inf <= (-inf - inf) which yields TRUE without forming any NaN. Although that conclusion seems weird at first glance, there seems no way to poke a hole in it without rejecting the principle that inf + inf = inf. Second, if -inf is included in the range that ends 'inf preceding' itself, symmetry dictates that it is also included in the range that begins 'inf following' itself. In that case we'd be trying to compute -inf >= (-inf + inf) which does involve a NaN, but this argument says we should return TRUE. The other three cases where we'd hit NaNs are likewise symmetric with non-NaN cases that'd return TRUE. Hence, I'm forced to the conclusion that you've got it right above. I might write the code a little differently, but const-TRUE-for-NaN-cases seems like the right behavior. So I withdraw my objection to defining it this way. Unless somebody else weighs in, I'll commit it like that in a day or two. regards, tom lane