| 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: | Whole Thread | Raw Message | 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 |