> To keep such kind of integrity, we should deeply consider about > errors.
My point is that I don't think we can keep integrity together with the fuzzy behaviour, or at least I don't have the skills to do that. I can just leave the more complicated operators like "is a point on a line" as it is, and only change the basic ones. Do you think a smaller patch like this would be acceptable? > That's a fate of FP numbers. Btree is uasble for such data since > it is constructed using inequality operators but hash is almost > unsuitable without rounding and normalization because of the > nature of floating point numbers. Range scan on bree will work > find but on the other hand equality doesn't work even on btree > index from the same reason to the below. Btree is very useful with floats. There is no problem with it. > Again, FP numbers generally cannot match exactly each other. You > have to avoid that. Again, they do match very well. Floating point numbers are no magic. They are perfectly deterministic. -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
