Re: Floating point comparison inconsistencies of the geometric types

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Emre Hasegeli <emre(at)hasegeli(dot)com>
Cc: 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-01-31 16:31:38
Message-ID: CA+TgmoZpd_aTg+aLHG777a5QWfxdGBE0750qityaMAWZwCeJGQ@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jan 26, 2017 at 5:53 AM, Emre Hasegeli <emre(at)hasegeli(dot)com> wrote:
> Though, I know the community is against behaviour changing GUCs. I
> will not spend more time on this, before I get positive feedback from
> others.

As if on cue, let me say that a behavior-changing GUC sounds like a
terrible idea to me. It's almost never good when a GUC can cause the
same queries to return answers in different sessions, and even worse,
it seems like the GUC might have the effect of letting us build
indexes that are only valid for the value of the GUC with which they
were built.

Backing up a bit here, have we lost track of the problem that we're
trying to solve? Tom gave his opinion here:

https://www.postgresql.org/message-id/3895.1464791274@sss.pgh.pa.us

But I don't see that the latest patch I can find does anything to fix
that. Now maybe that's not the problem that Emre is trying to solve,
but then it is not very clear to me what problem he IS trying to
solve. And I think Kyotaro Horiguchi is trying to solve yet another
problem which is again different. So IMHO the first task here is to
agree on a clear statement of what we'd like to fix, and then, given a
patch, we can judge whether it's fixed.

Maybe I'm being dumb here and it's clear to you guys what the issues
under discussion are. If so, apologies for that, but the thread has
gotten too theoretical for me and I can't figure out what the
top-level concern is any more. I believe we all agree these macros
are bad, but there seems to be no agreement that I can discern on what
would be better or why.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Pavan Deolasee 2017-01-31 16:38:19 Re: Patch: Write Amplification Reduction Method (WARM)
Previous Message Robert Haas 2017-01-31 16:17:03 Re: Proposal : For Auto-Prewarm.