Re: Wrong results from in_range() tests with infinite offset

I wrote:
> Dean Rasheed <dean(dot)a(dot)rasheed(at)gmail(dot)com> 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