Re: Floating point comparison inconsistencies of the geometric types

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