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
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. |