Re: Floating point comparison inconsistencies of the geometric types

From: Emre Hasegeli <emre(at)hasegeli(dot)com>
To: Kevin Grittner <kgrittn(at)gmail(dot)com>
Cc: PostgreSQL Hackers <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>, Robert Haas <robertmhaas(at)gmail(dot)com>, 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: 2016-09-04 17:42:33
Message-ID: CAE2gYzyLaf-g6PB40Pjy=1xT4-5NaP_Am2x6F=fDA0ZNoHwsvw@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> The first patch fails to apply due to bit-rot. That's easy enough
> to correct, but then it runs into warnings on make:

Rebased and fixed.

> Something to consider before posting new version -- should we
> change some of those macros to static inline (in the .h files) to
> avoid double-evaluation hazards? They might perform as well or
> even better that way, and remove a subtle programmer foot-gun.

One reason to keep them as macros is that they are currently
supporting both float4 and float8. Currently they look like this:

FLOAT_EQ(val1, val2)
FLOAT_PL(result, val1, val2)

I guess if we would use inline functions, they would look like:

FLOAT8_EQ(val1, val2)
result = FLOAT8_PL(val1, val2)

Result would need to be defined again in the function to be checked
for overflow. I think this way would be more developer-friendly. I
have gone some trouble to allocate the result to be able to use the
macros. Do you know if the performance of both would be the same?

I am not much experienced in C. If you think that inline functions
are better suited, I can rework the patches.

Attachment Content-Type Size
0001-float-header-v02.patch application/octet-stream 49.3 KB
0002-geo-ops-fpcomp-v02.patch application/octet-stream 244.1 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2016-09-04 17:44:06 Re: Better locale-specific-character-class handling for regexps
Previous Message Tom Lane 2016-09-04 17:01:12 Re: Transactional enum additions - was Re: Alter or rename enum value