From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> |
Cc: | Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: 'infinity' in GiST index |
Date: | 2005-05-05 04:16:46 |
Message-ID: | 18960.1115266606@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Oleg Bartunov <oleg(at)sai(dot)msu(dot)su> writes:
> there was complain about problem with creating GiST index if
> timestamp column contains 'infinity' value. The problem is indeed
> exists and I'd like to have it fixed, but we have no idea
> how to handle it in GiST, actually in penalty function.
> Any thoughts ?
Seems like it's not really GiST's fault but a definitional problem
for the timestamp datatype. Specifically, what does it mean to
subtract two infinite timestamps? I find it hard to assign a
value to any of these combinations:
+infinity minus +infinity
-infinity minus -infinity
+infinity minus -infinity
-infinity minus +infinity
The first two can't really be identified with zero, and the last two are
surely not representable are they?
What's worse, a subtraction involving one infinite and one finite
timestamp *is* well defined from a mathematical point of view, eg
+infinity minus 'yesterday' = +infinity
but I doubt GiST will be happy if we make the datatype behave that
way...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Josh Berkus | 2005-05-05 04:37:40 | Views, views, views! (long) |
Previous Message | Oleg Bartunov | 2005-05-05 04:05:01 | 'infinity' in GiST index |