Re: Floating point comparison inconsistencies of the geometric types

From: David Steele <david(at)pgmasters(dot)net>
To: emre(at)hasegeli(dot)com
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, Kyotaro HORIGUCHI <horiguchi(dot)kyotaro(at)lab(dot)ntt(dot)co(dot)jp>, Kevin Grittner <kgrittn(at)gmail(dot)com>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Andreas Karlsson <andreas(at)proxel(dot)se>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Kevin Grittner <kgrittn(at)ymail(dot)com>, Jim Nasby <Jim(dot)Nasby(at)bluetreble(dot)com>, Joe Conway <mail(at)joeconway(dot)com>
Subject: Re: Floating point comparison inconsistencies of the geometric types
Date: 2017-03-16 16:10:22
Views: Raw Message | Whole Thread | Download mbox | Resend email
Lists: pgsql-hackers

On 2/1/17 6:36 AM, Emre Hasegeli wrote:
>> Got it, but if other people don't agree then this is going nowhere.
> Yes. As I wrote, I don't particularly care about functions like "is
> point on line". I can prepare a patch to fix as many problems as
> possible around those operators by preserving the current epsilon.
> I though we were arguing about *all* operators. Having containment
> and placement operators consistent with each other, is the primary
> thing I am trying to fix. Is removing epsilon from them is
> acceptable?
> We can also stay away from changing operators like "~=" to minimise
> compatibility break, if we keep the epsilon on some places. We can
> instead document this operator as "close enough", and introduce
> another symbol for really "the same" operator.
> That said, there are some places where it is hard to decide to apply
> the epsilon or not. For example, we can keep the epsilon to check for
> two lines being parallel, but then should we return the intersection
> point, or not? Those issues may become more clear when I start
> working on it, if preserving epsilon for those operators is the way to
> go forward.

The current patches do not apply cleanly at cccbdde:

$ git apply ../other/0001-float-header-v03.patch
error: patch failed: contrib/btree_gist/btree_ts.c:1
error: contrib/btree_gist/btree_ts.c: patch does not apply
error: patch failed: contrib/postgres_fdw/postgres_fdw.c:26
error: contrib/postgres_fdw/postgres_fdw.c: patch does not apply
error: patch failed: src/backend/access/gist/gistutil.c:14
error: src/backend/access/gist/gistutil.c: patch does not apply
error: patch failed: src/backend/utils/adt/float.c:339
error: src/backend/utils/adt/float.c: patch does not apply
error: patch failed: src/backend/utils/adt/geo_ops.c:14
error: src/backend/utils/adt/geo_ops.c: patch does not apply
error: patch failed: src/backend/utils/misc/guc.c:68
error: src/backend/utils/misc/guc.c: patch does not apply
error: patch failed: src/include/utils/builtins.h:334
error: src/include/utils/builtins.h: patch does not apply

I don't believe this patch should be in the "Needs review" state anyway.
There are clearly a number of issues that need work and agreement.

Given that this thread has been idle since the beginning of February and
no resolution is likely for v10, I'm marking this submission "Returned
with Feedback".


In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message David Steele 2017-03-16 16:15:42 Re: PoC plpgsql - possibility to force custom or generic plan
Previous Message Ashutosh Sharma 2017-03-16 16:09:04 Re: Microvacuum support for Hash Index