Em sáb., 3 de set. de 2022 às 19:39, Daniel Gustafsson <
daniel@yesql.se> escreveu:
> On 3 Sep 2022, at 09:36, Julien Rouhaud <rjuju123@gmail.com> wrote:
> Yeah, there are unfortunately a lot of problems around those and NaN, with
> multiple reports in the past (I recall [1] and [2] but there were others).
NaNs are indeed incredibly complicated, but I think we are sort of in a good
place here given it's testing for equality in floats. The commit message of
c4c34008854654279ec30067d72fc5d174d2f42f carries an explanation:
The float datatypes consider NaNs values to be equal and greater than
all non-NaN values. This change considers NaNs equal only for equality
operators. The placement operators, contains, overlaps, left/right of
etc. continue to return false when NaNs are involved.
From testing and reading I believe the fix in this thread is correct, but since
NaNs are involved I will take another look at this with fresh eyes before going
ahead.
Yeah, the fix is correct.
But with Windows 10 build, I got this diff result:
diff -w -U3 C:/dll/postgres_dev/postgres_master/src/test/regress/expected/geometry.out C:/dll/postgres_dev/postgres_master/src/test/regress/results/geometry.out
--- C:/dll/postgres_dev/postgres_master/src/test/regress/expected/geometry.out 2022-09-01 08:05:03.685931000 -0300
+++ C:/dll/postgres_dev/postgres_master/src/test/regress/results/geometry.out 2022-09-04 09:27:47.133617800 -0300
@@ -4380,9 +4380,8 @@
<(100,200),10> | <(100,200),10>
<(100,1),115> | <(100,1),115>
<(3,5),0> | <(3,5),0>
- <(3,5),NaN> | <(3,5),0>
<(3,5),NaN> | <(3,5),NaN>
-(9 rows)
+(8 rows)
-- Overlap with circle
SELECT c1.f1, c2.f1 FROM CIRCLE_TBL c1, CIRCLE_TBL c2 WHERE c1.f1 && c2.f1;
Not sure why.
regards,
Ranier Vilela
