Hi there,

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 ?

Regards,
Oleg
__________________________________________________ ___________
Oleg Bartunov, sci.researcher, hostmaster of AstroNet,
Sternberg Astronomical Institute, Moscow University (Russia)
Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/
phone: +007(095)939-16-83, +007(095)939-23-83

---------------------------(end of broadcast)---------------------------
TIP 9: the planner will ignore your desire to choose an index scan if your
joining column's datatypes do not match

Oleg Bartunov <oleg@sai.msu.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

---------------------------(end of broadcast)---------------------------
TIP 3: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly