On Tue, 21 Jul 2020 at 03:06, Tom Lane wrote:
>
> Pushed, but I chickened out of back-patching. The improvement in what
> happens for finite comparison values seems somewhat counterbalanced by
> the possibility that someone might not like the definition we arrived
> at for infinities. So, it's n
I wrote:
> 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.
> S
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 outcom
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 inf
On Fri, 17 Jul 2020 at 01:59, Tom Lane wrote:
>
> Dean Rasheed writes:
> > On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> >> Actually, after staring at those results awhile longer, I decided
> >> they were wrong. The results shown here seem actually sane ---
> >> for instance, -Infinity shouldn'
Dean Rasheed writes:
> On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
>> Actually, after staring at those results awhile longer, I decided
>> they were wrong. The results shown here seem actually sane ---
>> for instance, -Infinity shouldn't "infinitely precede" itself,
>> I think. (Maybe if you g
On Thu, 16 Jul 2020, 22:50 Tom Lane, wrote:
> I wrote:
> > When the current row's value is +infinity, actual computation of
> > base - offset would yield NaN, making it a bit unclear whether
> > we should consider -infinity to be in-range. It seems to me that
> > we should, as that gives more na
I wrote:
> When the current row's value is +infinity, actual computation of
> base - offset would yield NaN, making it a bit unclear whether
> we should consider -infinity to be in-range. It seems to me that
> we should, as that gives more natural-looking results in the test
> cases, so that's how