database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2026-10-23 13:29:09 +03:00
Code Activity

Doc: correct overambitious precision claim for contrib/seg.

Browse Source 
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:
Tom Lane
2026-10-06 15:07:01 -04:00
parent c596e189df
commit 6236f8f398
1 changed files with 2 additions and 2 deletions
Download Patch File Download Diff File Expand all files Collapse all files

4
doc/src/sgml/seg.sgml
View File

@@ -225,12 +225,12 @@ test=&gt; 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