From 39883fa022aeba59c2570c5ab046af2307f85acf Mon Sep 17 00:00:00 2001 From: Tom Lane Date: Tue, 6 Oct 2026 15:07:01 -0400 Subject: [PATCH] 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 Author: Tom Lane Discussion: https://postgr.es/m/19744-8c700582bbb1d075@postgresql.org Backpatch-through: 14 --- doc/src/sgml/seg.sgml | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/seg.sgml b/doc/src/sgml/seg.sgml index dc66e24f2f5..c2a0c77a3e5 100644 --- a/doc/src/sgml/seg.sgml +++ b/doc/src/sgml/seg.sgml @@ -225,12 +225,12 @@ test=> select '6.25 .. 6.50'::seg as "pH"; seg 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. - 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