Use strtof() and not strtod() for float4 input.
Using strtod() creates a double-rounding problem; the input decimal
value is first rounded to the nearest double; rounding that to the
nearest float may then give an incorrect result.
An example is that 7.038531e-26 when input via strtod and then rounded
to float4 gives 0xAE43FEp-107 instead of the correct 0xAE43FDp-107.
Values output by earlier PG versions with extra_float_digits=3 should
all be read in with the same values as previously. However, values
supplied by other software using shortest representations could be
mis-read.
On platforms that lack a strtof() entirely, we fall back to the old
incorrect rounding behavior. (As strtof() is required by C99, such
platforms are considered of primarily historical interest.) On VS2013,
some workarounds are used to get correct error handling.
The regression tests now test for the correct input values, so
platforms that lack strtof() will need resultmap entries. An entry for
HP-UX 10 is included (more may be needed).
Reviewed-By: Tom Lane
Discussion: https://postgr.es/m/871s5emitx.fsf@news-spur.riddles.org.uk
Discussion: https://postgr.es/m/87d0owlqpv.fsf@news-spur.riddles.org.uk
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/f397e08599a3c3c08b3af3b318c531db5882f57d
Modified Files
--------------
configure | 13 +
configure.in | 1 +
src/backend/utils/adt/float.c | 56 ++-
src/include/pg_config.h.in | 3 +
src/include/pg_config.h.win32 | 3 +
src/include/port.h | 4 +
src/include/port/win32_port.h | 12 +
src/port/strtof.c | 123 ++++++
.../regress/expected/float4-misrounded-input.out | 436 +++++++++++++++++++++
src/test/regress/expected/float4.out | 136 ++++++-
src/test/regress/resultmap | 1 +
src/test/regress/sql/float4.sql | 37 ++
src/tools/msvc/Mkvcbuild.pm | 2 +
13 files changed, 810 insertions(+), 17 deletions(-)