On Tue, Aug 28, 2012 at 05:04:09PM -0400, Tom Lane wrote: > Robert Haas <robertmh...@gmail.com> writes: > > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > >> There's also the big-picture question of whether we should just get rid > >> of fuzzy comparisons in the geometric types instead of trying to hack > >> indexes to work around them. > > > +1 for that approach, but only if I don't have to do the work.
I agree in the abstract; why should a point (position on a 2D plane) compare fuzzily while a float8 (position on a 1D number line) does not? But ... > > Otherwise, +1 for doing the simplest thing that we're sure will > > eliminate wrong answers. > > What we're forced to speculate about here is how many applications out > there are relying on fuzzy comparison to get answers they like, versus > how many are getting answers they don't like because of it. The fact > that the underlying storage is float8 not numeric suggests there are > probably some cases where fuzzy is helpful. ... yes. Having never used these types in practice, I won't venture a guess. Anyone else? > I've never cared for the particulars of the way the fuzzy comparisons > are done, in any case: using an absolute rather than relative error > threshold is wrong according to every numerical analysis principle > I know. Definitely. > The long and the short of it is that it will probably take a significant > investment of work to make something that's clearly better. If that > weren't the case, we'd have done something long ago. In any event, I think we should entertain a patch to make the GiST operator class methods bug-compatible with corresponding operators. Even if we decide to change operator behavior in HEAD, the back branches could use it. Thanks, nm -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers