Re: [PATCH] Improve geometric types

On 08/01/2018 01:40 PM, Emre Hasegeli wrote:
>> Ah, so there's an assumption that NaNs are handled earlier and never reach
>> this place? That's probably a safe assumption. I haven't thought about that,
>> it simply seemed suspicious that the code mixes direct comparisons and
>> float8_mi() calls.
> 
> The comparison functions handle NaNs.  The arithmetic functions handle
> returning error on underflow, overflow and division by zero.  I
> assumed we want to return error on those in any case, but we don't
> want to handle NaNs at every place.
> 
>> Not sure, I'll leave that up to you. I don't mind doing it in a separate
>> patch (I'd probably prefer that over mixing it into unrelated patch).
> 
> It is attached separately.
> 

OK, thanks.

So, have we reached conclusion about all the bits I mentioned on 7/31? 
The delta and float8/double cast are fixed, and for computeDistance 
(i.e. doing comparisons directly or using float8_lt), the code may seem 
a bit inconsistent, but it is in fact correct as the NaNs are handled 
elsewhere. That seems reasonable, but perhaps a comment pointing that 
out would be nice.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services