Re: BUG #5592: list of integer undefined behaviors

Greg Stark <gsstark(at)mit(dot)edu> writes:
> On Tue, Aug 3, 2010 at 3:33 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> 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.

There is that. Given the lack of complaints from the field, maybe we
should leave it alone, except maybe for adding some more comments to
tinterval_cmp_internal.

> Also, does it cause any problem that this comparison function will
> treat large swathes of tintervals as equal?

Since we don't have hashing support for tinterval, there's nothing
inconsistent about the behavior. Whether it is *useful* is a whole
different discussion.

regards, tom lane