Fortify float4 and float8 regression tests by ordering test results
Hi, hackers!
I noticed that SELECT results in float4 and float8 tests lack ORDER BY
clauses. This makes test results depend on the current heap/MVCC
implementation.
If I try to run the float8 test on a table created with a different
access method provided by an extension, I'm getting results ordered
differently.
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries. I don't
have a strong opinion about backpatching this, but as the patch
changes only regression tests, it's maybe also worth backpatching.
Regards,
Pavel Borisov,
Supabase.
Attachments:
v1-0001-Fortify-float4-and-float8-tests-by-ordering-test-.patchapplication/octet-stream; name=v1-0001-Fortify-float4-and-float8-tests-by-ordering-test-.patchDownload
From bec122b31257ecf9f0fd84f6c957d436b9c96225 Mon Sep 17 00:00:00 2001
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Tue, 22 Apr 2025 17:17:38 +0400
Subject: [PATCH v1] Fortify float4 and float8 tests by ordering test results
---
src/test/regress/expected/float4.out | 70 ++++++++---------
src/test/regress/expected/float8.out | 108 +++++++++++++--------------
src/test/regress/sql/float4.sql | 28 +++----
src/test/regress/sql/float8.sql | 44 +++++------
4 files changed, 125 insertions(+), 125 deletions(-)
diff --git a/src/test/regress/expected/float4.out b/src/test/regress/expected/float4.out
index 1d21c4390ad..90b319e4737 100644
--- a/src/test/regress/expected/float4.out
+++ b/src/test/regress/expected/float4.out
@@ -186,136 +186,136 @@ SELECT 'nan'::numeric::float4;
NaN
(1 row)
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
---------------
+ -34.84
0
+ 1.2345679e-20
1004.3
- -34.84
1.2345679e+20
- 1.2345679e-20
(5 rows)
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <> '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <> '1004.3' ORDER BY 1;
f1
---------------
- 0
-34.84
- 1.2345679e+20
+ 0
1.2345679e-20
+ 1.2345679e+20
(4 rows)
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 = '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 = '1004.3' ORDER BY 1;
f1
--------
1004.3
(1 row)
-SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' > f.f1;
+SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' > f.f1 ORDER BY 1;
f1
---------------
- 0
-34.84
+ 0
1.2345679e-20
(3 rows)
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 < '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 < '1004.3' ORDER BY 1;
f1
---------------
- 0
-34.84
+ 0
1.2345679e-20
(3 rows)
-SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' >= f.f1;
+SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' >= f.f1 ORDER BY 1;
f1
---------------
- 0
- 1004.3
-34.84
+ 0
1.2345679e-20
+ 1004.3
(4 rows)
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <= '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <= '1004.3' ORDER BY 1;
f1
---------------
- 0
- 1004.3
-34.84
+ 0
1.2345679e-20
+ 1004.3
(4 rows)
SELECT f.f1, f.f1 * '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
---------------+----------------
+ 1.2345679e-20 | -1.2345678e-19
1004.3 | -10043
1.2345679e+20 | -1.2345678e+21
- 1.2345679e-20 | -1.2345678e-19
(3 rows)
SELECT f.f1, f.f1 + '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
---------------+---------------
+ 1.2345679e-20 | -10
1004.3 | 994.3
1.2345679e+20 | 1.2345679e+20
- 1.2345679e-20 | -10
(3 rows)
SELECT f.f1, f.f1 / '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
---------------+----------------
+ 1.2345679e-20 | -1.2345679e-21
1004.3 | -100.43
1.2345679e+20 | -1.2345679e+19
- 1.2345679e-20 | -1.2345679e-21
(3 rows)
SELECT f.f1, f.f1 - '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
---------------+---------------
+ 1.2345679e-20 | 10
1004.3 | 1014.3
1.2345679e+20 | 1.2345679e+20
- 1.2345679e-20 | 10
(3 rows)
-- test divide by zero
SELECT f.f1 / '0.0' from FLOAT4_TBL f;
ERROR: division by zero
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
---------------
+ -34.84
0
+ 1.2345679e-20
1004.3
- -34.84
1.2345679e+20
- 1.2345679e-20
(5 rows)
-- test the unary float4abs operator
-SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
+SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f ORDER BY 1;
f1 | abs_f1
---------------+---------------
+ -34.84 | 34.84
0 | 0
+ 1.2345679e-20 | 1.2345679e-20
1004.3 | 1004.3
- -34.84 | 34.84
1.2345679e+20 | 1.2345679e+20
- 1.2345679e-20 | 1.2345679e-20
(5 rows)
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
----------------
- 0
- -34.84
- -1004.3
-1.2345679e+20
+ -1004.3
+ -34.84
-1.2345679e-20
+ 0
(5 rows)
-- test edge-case coercions to integer
diff --git a/src/test/regress/expected/float8.out b/src/test/regress/expected/float8.out
index 10a5a6e1b65..19984a925ee 100644
--- a/src/test/regress/expected/float8.out
+++ b/src/test/regress/expected/float8.out
@@ -173,103 +173,103 @@ SELECT 'nan'::numeric::float8;
NaN
(1 row)
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
----------------------
+ -34.84
0
+ 1.2345678901234e-200
1004.3
- -34.84
1.2345678901234e+200
- 1.2345678901234e-200
(5 rows)
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <> '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <> '1004.3' ORDER BY 1;
f1
----------------------
- 0
-34.84
- 1.2345678901234e+200
+ 0
1.2345678901234e-200
+ 1.2345678901234e+200
(4 rows)
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 = '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 = '1004.3' ORDER BY 1;
f1
--------
1004.3
(1 row)
-SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' > f.f1;
+SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' > f.f1 ORDER BY 1;
f1
----------------------
- 0
-34.84
+ 0
1.2345678901234e-200
(3 rows)
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 < '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 < '1004.3' ORDER BY 1;
f1
----------------------
- 0
-34.84
+ 0
1.2345678901234e-200
(3 rows)
-SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' >= f.f1;
+SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' >= f.f1 ORDER BY 1;
f1
----------------------
- 0
- 1004.3
-34.84
+ 0
1.2345678901234e-200
+ 1004.3
(4 rows)
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <= '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <= '1004.3' ORDER BY 1;
f1
----------------------
- 0
- 1004.3
-34.84
+ 0
1.2345678901234e-200
+ 1004.3
(4 rows)
SELECT f.f1, f.f1 * '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
----------------------+-----------------------
+ 1.2345678901234e-200 | -1.2345678901234e-199
1004.3 | -10043
1.2345678901234e+200 | -1.2345678901234e+201
- 1.2345678901234e-200 | -1.2345678901234e-199
(3 rows)
SELECT f.f1, f.f1 + '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
----------------------+----------------------
+ 1.2345678901234e-200 | -10
1004.3 | 994.3
1.2345678901234e+200 | 1.2345678901234e+200
- 1.2345678901234e-200 | -10
(3 rows)
SELECT f.f1, f.f1 / '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
----------------------+-----------------------
+ 1.2345678901234e-200 | -1.2345678901234e-201
1004.3 | -100.42999999999999
1.2345678901234e+200 | -1.2345678901234e+199
- 1.2345678901234e-200 | -1.2345678901234e-201
(3 rows)
SELECT f.f1, f.f1 - '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | x
----------------------+----------------------
+ 1.2345678901234e-200 | 10
1004.3 | 1014.3
1.2345678901234e+200 | 1.2345678901234e+200
- 1.2345678901234e-200 | 10
(3 rows)
SELECT f.f1 ^ '2.0' AS square_f1
@@ -281,38 +281,38 @@ SELECT f.f1 ^ '2.0' AS square_f1
-- absolute value
SELECT f.f1, @f.f1 AS abs_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
f1 | abs_f1
----------------------+----------------------
+ -34.84 | 34.84
0 | 0
+ 1.2345678901234e-200 | 1.2345678901234e-200
1004.3 | 1004.3
- -34.84 | 34.84
1.2345678901234e+200 | 1.2345678901234e+200
- 1.2345678901234e-200 | 1.2345678901234e-200
(5 rows)
-- truncate
SELECT f.f1, trunc(f.f1) AS trunc_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
f1 | trunc_f1
----------------------+----------------------
+ -34.84 | -34
0 | 0
+ 1.2345678901234e-200 | 0
1004.3 | 1004
- -34.84 | -34
1.2345678901234e+200 | 1.2345678901234e+200
- 1.2345678901234e-200 | 0
(5 rows)
-- round
SELECT f.f1, round(f.f1) AS round_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
f1 | round_f1
----------------------+----------------------
+ -34.84 | -35
0 | 0
+ 1.2345678901234e-200 | 0
1004.3 | 1004
- -34.84 | -35
1.2345678901234e+200 | 1.2345678901234e+200
- 1.2345678901234e-200 | 0
(5 rows)
-- ceil / ceiling
@@ -375,12 +375,12 @@ SELECT |/ float8 '64' AS eight;
SELECT f.f1, |/f.f1 AS sqrt_f1
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | sqrt_f1
----------------------+-----------------------
+ 1.2345678901234e-200 | 1.11111110611109e-100
1004.3 | 31.6906926399535
1.2345678901234e+200 | 1.11111110611109e+100
- 1.2345678901234e-200 | 1.11111110611109e-100
(3 rows)
-- power
@@ -585,12 +585,12 @@ SELECT power(float8 '-inf', float8 '-inf');
-- take exp of ln(f.f1)
SELECT f.f1, exp(ln(f.f1)) AS exp_ln_f1
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
f1 | exp_ln_f1
----------------------+-----------------------
+ 1.2345678901234e-200 | 1.23456789012339e-200
1004.3 | 1004.3
1.2345678901234e+200 | 1.23456789012338e+200
- 1.2345678901234e-200 | 1.23456789012339e-200
(3 rows)
-- check edge cases for exp
@@ -607,24 +607,24 @@ SELECT ||/ float8 '27' AS three;
3
(1 row)
-SELECT f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f;
+SELECT f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f ORDER BY 1;
f1 | cbrt_f1
----------------------+----------------------
+ -34.84 | -3.26607421344208
0 | 0
+ 1.2345678901234e-200 | 2.3112042409018e-67
1004.3 | 10.014312837827
- -34.84 | -3.26607421344208
1.2345678901234e+200 | 4.97933859234765e+66
- 1.2345678901234e-200 | 2.3112042409018e-67
(5 rows)
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
----------------------
+ -34.84
0
+ 1.2345678901234e-200
1004.3
- -34.84
1.2345678901234e+200
- 1.2345678901234e-200
(5 rows)
UPDATE FLOAT8_TBL
@@ -640,22 +640,22 @@ SELECT 0 ^ 0 + 0 ^ 1 + 0 ^ 0.0 + 0 ^ 0.5;
2
(1 row)
-SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
+SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0';
ERROR: cannot take logarithm of zero
-SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 < '0.0' ;
+SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 < '0.0';
ERROR: cannot take logarithm of a negative number
SELECT exp(f.f1) from FLOAT8_TBL f;
ERROR: value out of range: underflow
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
ERROR: division by zero
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
-----------------------
- 0
- -34.84
- -1004.3
-1.2345678901234e+200
+ -1004.3
+ -34.84
-1.2345678901234e-200
+ 0
(5 rows)
-- hyperbolic functions
@@ -906,14 +906,14 @@ LINE 1: INSERT INTO FLOAT8_TBL(f1) VALUES ('-10e-400');
^
DROP TABLE FLOAT8_TBL;
-- Check the float8 values exported for use by other tests
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
-----------------------
- 0
- -34.84
- -1004.3
-1.2345678901234e+200
+ -1004.3
+ -34.84
-1.2345678901234e-200
+ 0
(5 rows)
-- test edge-case coercions to integer
diff --git a/src/test/regress/sql/float4.sql b/src/test/regress/sql/float4.sql
index 8fb12368c39..f13cb7c50f8 100644
--- a/src/test/regress/sql/float4.sql
+++ b/src/test/regress/sql/float4.sql
@@ -60,45 +60,45 @@ SELECT 'nan'::float4 / 'nan'::float4;
SELECT 'nan'::float4 / '0'::float4;
SELECT 'nan'::numeric::float4;
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <> '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <> '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 = '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 = '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' > f.f1;
+SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' > f.f1 ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 < '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 < '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' >= f.f1;
+SELECT f.* FROM FLOAT4_TBL f WHERE '1004.3' >= f.f1 ORDER BY 1;
-SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <= '1004.3';
+SELECT f.* FROM FLOAT4_TBL f WHERE f.f1 <= '1004.3' ORDER BY 1;
SELECT f.f1, f.f1 * '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 + '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 / '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 - '-10' AS x FROM FLOAT4_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
-- test divide by zero
SELECT f.f1 / '0.0' from FLOAT4_TBL f;
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
-- test the unary float4abs operator
-SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
+SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f ORDER BY 1;
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
-- test edge-case coercions to integer
SELECT '32767.4'::float4::int2;
diff --git a/src/test/regress/sql/float8.sql b/src/test/regress/sql/float8.sql
index db8d5724c25..e7b8ac8fbb1 100644
--- a/src/test/regress/sql/float8.sql
+++ b/src/test/regress/sql/float8.sql
@@ -58,50 +58,50 @@ SELECT 'nan'::float8 / 'nan'::float8;
SELECT 'nan'::float8 / '0'::float8;
SELECT 'nan'::numeric::float8;
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <> '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <> '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 = '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 = '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' > f.f1;
+SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' > f.f1 ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 < '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 < '1004.3' ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' >= f.f1;
+SELECT f.* FROM FLOAT8_TBL f WHERE '1004.3' >= f.f1 ORDER BY 1;
-SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <= '1004.3';
+SELECT f.* FROM FLOAT8_TBL f WHERE f.f1 <= '1004.3' ORDER BY 1;
SELECT f.f1, f.f1 * '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 + '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 / '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1, f.f1 - '-10' AS x
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
SELECT f.f1 ^ '2.0' AS square_f1
FROM FLOAT8_TBL f where f.f1 = '1004.3';
-- absolute value
SELECT f.f1, @f.f1 AS abs_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
-- truncate
SELECT f.f1, trunc(f.f1) AS trunc_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
-- round
SELECT f.f1, round(f.f1) AS round_f1
- FROM FLOAT8_TBL f;
+ FROM FLOAT8_TBL f ORDER BY 1;
-- ceil / ceiling
select ceil(f1) as ceil_f1 from float8_tbl f;
@@ -123,7 +123,7 @@ SELECT |/ float8 '64' AS eight;
SELECT f.f1, |/f.f1 AS sqrt_f1
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
-- power
SELECT power(float8 '144', float8 '0.5');
@@ -166,7 +166,7 @@ SELECT power(float8 '-inf', float8 '-inf');
-- take exp of ln(f.f1)
SELECT f.f1, exp(ln(f.f1)) AS exp_ln_f1
FROM FLOAT8_TBL f
- WHERE f.f1 > '0.0';
+ WHERE f.f1 > '0.0' ORDER BY 1;
-- check edge cases for exp
SELECT exp('inf'::float8), exp('-inf'::float8), exp('nan'::float8);
@@ -174,10 +174,10 @@ SELECT exp('inf'::float8), exp('-inf'::float8), exp('nan'::float8);
-- cube root
SELECT ||/ float8 '27' AS three;
-SELECT f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f;
+SELECT f.f1, ||/f.f1 AS cbrt_f1 FROM FLOAT8_TBL f ORDER BY 1;
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
UPDATE FLOAT8_TBL
SET f1 = FLOAT8_TBL.f1 * '-1'
@@ -189,15 +189,15 @@ SELECT f.f1 ^ '1e200' from FLOAT8_TBL f;
SELECT 0 ^ 0 + 0 ^ 1 + 0 ^ 0.0 + 0 ^ 0.5;
-SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0' ;
+SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 = '0.0';
-SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 < '0.0' ;
+SELECT ln(f.f1) from FLOAT8_TBL f where f.f1 < '0.0';
SELECT exp(f.f1) from FLOAT8_TBL f;
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
-- hyperbolic functions
-- we run these with extra_float_digits = 0 too, since different platforms
@@ -281,7 +281,7 @@ DROP TABLE FLOAT8_TBL;
-- Check the float8 values exported for use by other tests
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
-- test edge-case coercions to integer
SELECT '32767.4'::float8::int2;
--
2.39.2 (Apple Git-143)
Hi Pavel,
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries.
Thanks for the patch. That's a good change IMO.
I don't
have a strong opinion about backpatching this, but as the patch
changes only regression tests, it's maybe also worth backpatching.
I don't see a reason for backpatching this but I'm not strongly
opposed to the idea either.
--
Best regards,
Aleksander Alekseev
Pavel Borisov <pashkin.elfe@gmail.com> writes:
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries.
You do realize that this problem is hardly confined to the
float4 and float8 tests? To a first approximation, a table AM
that fails to preserve insertion order would break every single
one of our regression tests. (I speak from experience, as
Salesforce had to deal with this when I was there...)
The reason why we don't simply add ORDER BY to everything is
explained at [1]https://www.postgresql.org/docs/devel/regress-evaluation.html#REGRESS-EVALUATION-ORDERING-DIFFERENCES:
You might wonder why we don't order all the regression test
queries explicitly to get rid of this issue once and for all. The
reason is that that would make the regression tests less useful,
not more, since they'd tend to exercise query plan types that
produce ordered results to the exclusion of those that don't.
At some point we will probably have to think through what we
want to do about running the regression tests with table AMs that
don't wish to preserve ordering as much as heapam does. It's going
to need careful balancing of multiple concerns, and I don't think
"blindly slap ORDER BY everywhere" is going to be an acceptable
answer.
regards, tom lane
Hi, Tom!
On Tue, 22 Apr 2025 at 18:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries.You do realize that this problem is hardly confined to the
float4 and float8 tests? To a first approximation, a table AM
that fails to preserve insertion order would break every single
one of our regression tests. (I speak from experience, as
Salesforce had to deal with this when I was there...)The reason why we don't simply add ORDER BY to everything is
explained at [1]:You might wonder why we don't order all the regression test
queries explicitly to get rid of this issue once and for all. The
reason is that that would make the regression tests less useful,
not more, since they'd tend to exercise query plan types that
produce ordered results to the exclusion of those that don't.At some point we will probably have to think through what we
want to do about running the regression tests with table AMs that
don't wish to preserve ordering as much as heapam does. It's going
to need careful balancing of multiple concerns, and I don't think
"blindly slap ORDER BY everywhere" is going to be an acceptable
answer.
I agree we might need to elaborate different AM support in regression tests.
Also, I agree that these are not the only tests to be fixed.
What I hardly agree with, is that we suppose it's right for regression
tests to require some fixed results ordering for so simple cases.
Maybe for more complicated plans it's useful, but for the float tests
mentioned in the patch it's this requirement is a total loss IMO.
I understand your sentiment against blindly slapping order by's, but I
don't see a useful alternative for this time. Also a large number of
tests in PG were already fortified with ORDER BY 1.
Regards,
Pavel Borisov
Supabase
On Tue, 22 Apr 2025 at 18:40, Pavel Borisov <pashkin.elfe@gmail.com> wrote:
Hi, Tom!
On Tue, 22 Apr 2025 at 18:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries.You do realize that this problem is hardly confined to the
float4 and float8 tests? To a first approximation, a table AM
that fails to preserve insertion order would break every single
one of our regression tests. (I speak from experience, as
Salesforce had to deal with this when I was there...)The reason why we don't simply add ORDER BY to everything is
explained at [1]:You might wonder why we don't order all the regression test
queries explicitly to get rid of this issue once and for all. The
reason is that that would make the regression tests less useful,
not more, since they'd tend to exercise query plan types that
produce ordered results to the exclusion of those that don't.At some point we will probably have to think through what we
want to do about running the regression tests with table AMs that
don't wish to preserve ordering as much as heapam does. It's going
to need careful balancing of multiple concerns, and I don't think
"blindly slap ORDER BY everywhere" is going to be an acceptable
answer.I agree we might need to elaborate different AM support in regression tests.
Also, I agree that these are not the only tests to be fixed.What I hardly agree with, is that we suppose it's right for regression
tests to require some fixed results ordering for so simple cases.
Maybe for more complicated plans it's useful, but for the float tests
mentioned in the patch it's this requirement is a total loss IMO.I understand your sentiment against blindly slapping order by's, but I
don't see a useful alternative for this time. Also a large number of
tests in PG were already fortified with ORDER BY 1.
I forgot to mention that it's not only a question of INSERTs ordering.
Extension AM can have some internal ordering e.g. index-organized
tables. And besides SELECT query results following internal AM
ordering just being allowed, more importantly they are good
performance-wise and justify table AM extensibility.
Regards,
Pavel.
On Tue, Apr 22, 2025 at 5:57 PM Pavel Borisov <pashkin.elfe@gmail.com>
wrote:
On Tue, 22 Apr 2025 at 18:40, Pavel Borisov <pashkin.elfe@gmail.com>
wrote:
On Tue, 22 Apr 2025 at 18:23, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
It's not a big problem, but propose a simple fix for the tests. It
just adds ORDER BY 1 to all relevant float4 and floa8 queries.You do realize that this problem is hardly confined to the
float4 and float8 tests? To a first approximation, a table AM
that fails to preserve insertion order would break every single
one of our regression tests. (I speak from experience, as
Salesforce had to deal with this when I was there...)The reason why we don't simply add ORDER BY to everything is
explained at [1]:You might wonder why we don't order all the regression test
queries explicitly to get rid of this issue once and for all. The
reason is that that would make the regression tests less useful,
not more, since they'd tend to exercise query plan types that
produce ordered results to the exclusion of those that don't.At some point we will probably have to think through what we
want to do about running the regression tests with table AMs that
don't wish to preserve ordering as much as heapam does. It's going
to need careful balancing of multiple concerns, and I don't think
"blindly slap ORDER BY everywhere" is going to be an acceptable
answer.I agree we might need to elaborate different AM support in regression
tests.
Also, I agree that these are not the only tests to be fixed.
What I hardly agree with, is that we suppose it's right for regression
tests to require some fixed results ordering for so simple cases.
Maybe for more complicated plans it's useful, but for the float tests
mentioned in the patch it's this requirement is a total loss IMO.I understand your sentiment against blindly slapping order by's, but I
don't see a useful alternative for this time. Also a large number of
tests in PG were already fortified with ORDER BY 1.I forgot to mention that it's not only a question of INSERTs ordering.
Extension AM can have some internal ordering e.g. index-organized
tables. And besides SELECT query results following internal AM
ordering just being allowed, more importantly they are good
performance-wise and justify table AM extensibility.
+1,
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.
-- test the unary float4abs operator
SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
f1 | abs_f1
---------------+---------------
0 | 0
1004.3 | 1004.3
-34.84 | 34.84
1.2345679e+20 | 1.2345679e+20
1.2345679e-20 | 1.2345679e-20
(5 rows)
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
SELECT * FROM FLOAT4_TBL;
f1
----------------
0
-34.84
-1004.3
-1.2345679e+20
-1.2345679e-20
(5 rows)
------
Regards,
Alexander Korotkov
Supabase
Alexander Korotkov <aekorotkov@gmail.com> writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.
I'd be willing to consider a policy that we don't want to depend on
exactly where UPDATE moves rows to. The proposed patch is not that,
however.
regards, tom lane
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.I'd be willing to consider a policy that we don't want to depend on
exactly where UPDATE moves rows to. The proposed patch is not that,
however.
OK, that makes sense for me.
------
Regards,
Alexander Korotkov
Supabase
Hi!
On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.I'd be willing to consider a policy that we don't want to depend on
exactly where UPDATE moves rows to. The proposed patch is not that,
however.OK, that makes sense for me.
Thanks for this input!
This was my first intention to fix only the test that was affected by
UPDATE-order specifics, broke when runnung on an extension AM.
Maybe I was too liberal and added ORDER BY's more than needed.
I definitely agree to the proposal.
Please find attached v2 that fixes only UPDATE-specific part of
float4/float8 test.
Attachments:
v2-0001-Fortify-float4-and-float8-regression-tests-agains.patchapplication/octet-stream; name=v2-0001-Fortify-float4-and-float8-regression-tests-agains.patchDownload
From f893a83777c558412e402bd4ac7f720c36fcdedd Mon Sep 17 00:00:00 2001
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Tue, 22 Apr 2025 20:41:59 +0400
Subject: [PATCH v2] Fortify float4 and float8 regression tests against
difference in rows order introduced by UPDATEs
---
src/test/regress/expected/float4.out | 8 ++++----
src/test/regress/expected/float8.out | 8 ++++----
src/test/regress/sql/float4.sql | 2 +-
src/test/regress/sql/float8.sql | 2 +-
4 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/src/test/regress/expected/float4.out b/src/test/regress/expected/float4.out
index 1d21c4390ad..eaed1f2bfe7 100644
--- a/src/test/regress/expected/float4.out
+++ b/src/test/regress/expected/float4.out
@@ -308,14 +308,14 @@ SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
----------------
- 0
- -34.84
- -1004.3
-1.2345679e+20
+ -1004.3
+ -34.84
-1.2345679e-20
+ 0
(5 rows)
-- test edge-case coercions to integer
diff --git a/src/test/regress/expected/float8.out b/src/test/regress/expected/float8.out
index 10a5a6e1b65..9c519f1a1a1 100644
--- a/src/test/regress/expected/float8.out
+++ b/src/test/regress/expected/float8.out
@@ -648,14 +648,14 @@ SELECT exp(f.f1) from FLOAT8_TBL f;
ERROR: value out of range: underflow
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
ERROR: division by zero
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
-----------------------
- 0
- -34.84
- -1004.3
-1.2345678901234e+200
+ -1004.3
+ -34.84
-1.2345678901234e-200
+ 0
(5 rows)
-- hyperbolic functions
diff --git a/src/test/regress/sql/float4.sql b/src/test/regress/sql/float4.sql
index 8fb12368c39..44418a64002 100644
--- a/src/test/regress/sql/float4.sql
+++ b/src/test/regress/sql/float4.sql
@@ -98,7 +98,7 @@ UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
-- test edge-case coercions to integer
SELECT '32767.4'::float4::int2;
diff --git a/src/test/regress/sql/float8.sql b/src/test/regress/sql/float8.sql
index db8d5724c25..0ef271f2702 100644
--- a/src/test/regress/sql/float8.sql
+++ b/src/test/regress/sql/float8.sql
@@ -197,7 +197,7 @@ SELECT exp(f.f1) from FLOAT8_TBL f;
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
-- hyperbolic functions
-- we run these with extra_float_digits = 0 too, since different platforms
--
2.39.2 (Apple Git-143)
Pavel Borisov <pashkin.elfe@gmail.com> writes:
On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.
I'd be willing to consider a policy that we don't want to depend on
exactly where UPDATE moves rows to. The proposed patch is not that,
however.
OK, that makes sense for me.
Thanks for this input!
This was my first intention to fix only the test that was affected by
UPDATE-order specifics, broke when runnung on an extension AM.
Maybe I was too liberal and added ORDER BY's more than needed.
I definitely agree to the proposal.
On further reflection, this policy makes plenty of sense because even
heapam is not all that stable about row order after UPDATE. With
tables large enough to draw the attention of autovacuum, we've had
to use ORDER BY or other techniques to stabilize the results, because
the timing of background autovacuums affected where rows got put.
These tests are different only because the tables are small enough
and the updates few enough that autovacuum doesn't get involved.
I think it's reasonable that at a project-policy level we should
not consider that an excuse. For example, a change in autovacuum's
rules could probably break these tests even with heapam.
On the other hand, as I mentioned earlier, a table AM that doesn't
reproduce original insertion order would break a whole lot more
tests than these. So that's a bridge I'd rather not cross,
at least not without a lot of consideration.
BTW, you forgot to update expected/float4-misrounded-input.out.
regards, tom lane
Hi, Tom!
On Tue, 22 Apr 2025 at 21:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
On Tue, 22 Apr 2025 at 20:22, Alexander Korotkov <aekorotkov@gmail.com> wrote:
On Tue, Apr 22, 2025 at 7:20 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
Alexander Korotkov <aekorotkov@gmail.com> writes:
I'd like to add that float4.out not only assumes that insert-ordering is
preserved (this could be more-or-less portable between table AMs). It also
assumes the way UPDATE moves updated rows. That seems quite
heap-specific. You can see in the following fragment, updated rows jump to
the bottom.I'd be willing to consider a policy that we don't want to depend on
exactly where UPDATE moves rows to. The proposed patch is not that,
however.OK, that makes sense for me.
Thanks for this input!
This was my first intention to fix only the test that was affected by
UPDATE-order specifics, broke when runnung on an extension AM.
Maybe I was too liberal and added ORDER BY's more than needed.
I definitely agree to the proposal.On further reflection, this policy makes plenty of sense because even
heapam is not all that stable about row order after UPDATE. With
tables large enough to draw the attention of autovacuum, we've had
to use ORDER BY or other techniques to stabilize the results, because
the timing of background autovacuums affected where rows got put.
These tests are different only because the tables are small enough
and the updates few enough that autovacuum doesn't get involved.
I think it's reasonable that at a project-policy level we should
not consider that an excuse. For example, a change in autovacuum's
rules could probably break these tests even with heapam.On the other hand, as I mentioned earlier, a table AM that doesn't
reproduce original insertion order would break a whole lot more
tests than these. So that's a bridge I'd rather not cross,
at least not without a lot of consideration.BTW, you forgot to update expected/float4-misrounded-input.out.
Added in v3. Thanks for a mention!
Regards,
Pavel Borisov
Attachments:
v3-0001-Fortify-float4-and-float8-regression-tests-agains.patchapplication/octet-stream; name=v3-0001-Fortify-float4-and-float8-regression-tests-agains.patchDownload
From bab58d5651cb9f3f5afaa8434c899bc124b2b48d Mon Sep 17 00:00:00 2001
From: Pavel Borisov <pashkin.elfe@gmail.com>
Date: Tue, 22 Apr 2025 20:41:59 +0400
Subject: [PATCH v3] Fortify float4 and float8 regression tests against
difference in rows order introduced by UPDATEs
---
src/test/regress/expected/float4-misrounded-input.out | 8 ++++----
src/test/regress/expected/float4.out | 8 ++++----
src/test/regress/expected/float8.out | 8 ++++----
src/test/regress/sql/float4.sql | 2 +-
src/test/regress/sql/float8.sql | 2 +-
5 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/src/test/regress/expected/float4-misrounded-input.out b/src/test/regress/expected/float4-misrounded-input.out
index 20fd7139136..61c68a6c9ff 100644
--- a/src/test/regress/expected/float4-misrounded-input.out
+++ b/src/test/regress/expected/float4-misrounded-input.out
@@ -308,14 +308,14 @@ SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
----------------
- 0
- -34.84
- -1004.3
-1.2345679e+20
+ -1004.3
+ -34.84
-1.2345679e-20
+ 0
(5 rows)
-- test edge-case coercions to integer
diff --git a/src/test/regress/expected/float4.out b/src/test/regress/expected/float4.out
index 1d21c4390ad..eaed1f2bfe7 100644
--- a/src/test/regress/expected/float4.out
+++ b/src/test/regress/expected/float4.out
@@ -308,14 +308,14 @@ SELECT f.f1, @f.f1 AS abs_f1 FROM FLOAT4_TBL f;
UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
f1
----------------
- 0
- -34.84
- -1004.3
-1.2345679e+20
+ -1004.3
+ -34.84
-1.2345679e-20
+ 0
(5 rows)
-- test edge-case coercions to integer
diff --git a/src/test/regress/expected/float8.out b/src/test/regress/expected/float8.out
index 10a5a6e1b65..9c519f1a1a1 100644
--- a/src/test/regress/expected/float8.out
+++ b/src/test/regress/expected/float8.out
@@ -648,14 +648,14 @@ SELECT exp(f.f1) from FLOAT8_TBL f;
ERROR: value out of range: underflow
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
ERROR: division by zero
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
f1
-----------------------
- 0
- -34.84
- -1004.3
-1.2345678901234e+200
+ -1004.3
+ -34.84
-1.2345678901234e-200
+ 0
(5 rows)
-- hyperbolic functions
diff --git a/src/test/regress/sql/float4.sql b/src/test/regress/sql/float4.sql
index 8fb12368c39..44418a64002 100644
--- a/src/test/regress/sql/float4.sql
+++ b/src/test/regress/sql/float4.sql
@@ -98,7 +98,7 @@ UPDATE FLOAT4_TBL
SET f1 = FLOAT4_TBL.f1 * '-1'
WHERE FLOAT4_TBL.f1 > '0.0';
-SELECT * FROM FLOAT4_TBL;
+SELECT * FROM FLOAT4_TBL ORDER BY 1;
-- test edge-case coercions to integer
SELECT '32767.4'::float4::int2;
diff --git a/src/test/regress/sql/float8.sql b/src/test/regress/sql/float8.sql
index db8d5724c25..0ef271f2702 100644
--- a/src/test/regress/sql/float8.sql
+++ b/src/test/regress/sql/float8.sql
@@ -197,7 +197,7 @@ SELECT exp(f.f1) from FLOAT8_TBL f;
SELECT f.f1 / '0.0' from FLOAT8_TBL f;
-SELECT * FROM FLOAT8_TBL;
+SELECT * FROM FLOAT8_TBL ORDER BY 1;
-- hyperbolic functions
-- we run these with extra_float_digits = 0 too, since different platforms
--
2.39.2 (Apple Git-143)
Pavel Borisov <pashkin.elfe@gmail.com> writes:
On Tue, 22 Apr 2025 at 21:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
BTW, you forgot to update expected/float4-misrounded-input.out.
Added in v3. Thanks for a mention!
v3 LGTM, pushed.
regards, tom lane
On Tue, 22 Apr 2025 at 22:25, Tom Lane <tgl@sss.pgh.pa.us> wrote:
Pavel Borisov <pashkin.elfe@gmail.com> writes:
On Tue, 22 Apr 2025 at 21:13, Tom Lane <tgl@sss.pgh.pa.us> wrote:
BTW, you forgot to update expected/float4-misrounded-input.out.
Added in v3. Thanks for a mention!
v3 LGTM, pushed.
Thank you!
Regards,
Pavel