On Tue, Aug 28, 2012 at 05:04:09PM -0400, Tom Lane wrote:
> Robert Haas <robertmhaas@gmail.com> writes:
> > On Mon, Aug 27, 2012 at 7:43 PM, Tom Lane <tgl@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
