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