From: Tom Lane <tgl@sss.pgh.pa.us>
To: Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
cc: adrian.klaver@aklaver.com, frazer@frazermclean.co.uk,
        pgsql-general@postgresql.org
Subject: Re: Unexpected interval comparison
In-reply-to: <20170331.142157.204383147.horiguchi.kyotaro@lab.ntt.co.jp>
References: <375c9e5a-960f-942c-913f-55632a1f0a90@aklaver.com>
 <20170330.164651.249668658.horiguchi.kyotaro@lab.ntt.co.jp>
 <2087.1490885839@sss.pgh.pa.us>
 <20170331.142157.204383147.horiguchi.kyotaro@lab.ntt.co.jp>
Comments: In-reply-to Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp>
	message dated "Fri, 31 Mar 2017 14:21:57 +0900"
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <10352.1490981364.1@sss.pgh.pa.us>
Content-Transfer-Encoding: quoted-printable
Date: Fri, 31 Mar 2017 13:29:24 -0400
Message-ID: <10353.1490981364@sss.pgh.pa.us>
Precedence: bulk
Sender: pgsql-general-owner@postgresql.org

Kyotaro HORIGUCHI <horiguchi.kyotaro@lab.ntt.co.jp> writes:
> At Thu, 30 Mar 2017 10:57:19 -0400, Tom Lane <tgl@sss.pgh.pa.us> wrote in=
 <2087.1490885839@sss.pgh.pa.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.
>>=20
>> 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


--=20
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general