Re: Unexpected interval comparison

Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp> writes:
> At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote in <2087(dot)1490885839(at)sss(dot)pgh(dot)pa(dot)us>
>> A possible solution is to manually work in wider-than-64-bit
>> arithmetic, that is compute the comparison values div and mod
>> some pretty-large number and then compare the two halves.
>> I seem to recall that we did something similar in a few cases
>> years ago, before we were willing to assume that every machine
>> had 64-bit integer support.
>>
>> Of course, for machines having int128, you could just use that
>> type directly. I'm not sure how widespread that support is
>> nowadays. Maybe a 95%-good-enough solution is to use int128
>> if available and otherwise throw errors for intervals exceeding
>> 64 bits.

> int128 is seen in numeric.c. It is doable in the same manner. In
> that case it will be a bit slower on the platforms without
> int128.

> By the way is it right that we don't assume this as a bug-fix
> which should be done in the Pg10 dev cycle, but an improvement
> for 11?

Well, it seems like a bug to me. We might conclude that the fix
is too risky to back-patch, but it's hard to make that decision
before having a patch in hand to evaluate.

regards, tom lane