Re: BUG #5592: list of integer undefined behaviors

On Tue, Aug 3, 2010 at 3:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Although this is the worst case, you could easily get overflows from
> intervals with ordinary endpoints that are sufficiently far apart.

Oh, duh, this is pretty obvious in retrospect.

> Since this is a nearly-dead legacy datatype, I can't get excited about
> spending a lot of time on it.  What I suggest we do is do the difference
> calculation in int64 arithmetic instead of int32.

At some level this is all not really a problem. It just means that the
arbitrary ordering of tintervals isn't the obvious ordering. If we
change it it would invalidate any indexes on tintervals so it can't be
backpatched. I'm not sure whether it makes sense to bother having a
slightly more sensible ordering in 9.0+ if it's still going to be
wacky in older versions.

Also, does it cause any problem that this comparison function will
treat large swathes of tintervals as equal? Any tinterval with the
same length will compare equal according to this. I suppose it doesn't
have the same problem as strings as long as = is defined compatibly.

--
greg