mirror of
https://github.com/postgres/postgres.git
synced 2026-10-23 13:29:09 +03:00
Doc: correct overambitious precision claim for contrib/seg.
seg.sgml claims that a seg can store 7 significant digits, but this
is nonsense. The underlying float4 data type is not (quite) that
precise, and seg_out() intentionally rounds off to at most FLT_DIG
decimal places. With IEEE float arithmetic, FLT_DIG will be defined
as 6, or at least that's the case on all platforms I know of.
AFAICT this thinko goes clear back to the introduction of seg
(commit a3694b420), but it wasn't questioned until now.
Bug: #19744
Reported-by: Ke <kehan5800@gmail.com>
Author: Tom Lane <tgl@sss.pgh.pa.us>
Discussion: https://postgr.es/m/19744-8c700582bbb1d075@postgresql.org
Backpatch-through: 14
This commit is contained in:
@@ -225,12 +225,12 @@ test=> SELECT '6.25 .. 6.50'::seg AS "pH";
|
||||
|
||||
<para>
|
||||
<type>seg</type> values are stored internally as pairs of 32-bit floating point
|
||||
numbers. This means that numbers with more than 7 significant digits
|
||||
numbers. This means that numbers with more than 6 significant digits
|
||||
will be truncated.
|
||||
</para>
|
||||
|
||||
<para>
|
||||
Numbers with 7 or fewer significant digits retain their
|
||||
Numbers with 6 or fewer significant digits retain their
|
||||
original precision. That is, if your query returns 0.00, you will be
|
||||
sure that the trailing zeroes are not the artifacts of formatting: they
|
||||
reflect the precision of the original data. The number of leading
|
||||
|
||||
Reference in New Issue
Block a user