On Tue, Aug 3, 2010 at 3:33 AM, Tom Lane <t...@sss.pgh.pa.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 -- Sent via pgsql-bugs mailing list (pgsql-bugs@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-bugs
