Re: BUG #19744: contrib/seg output truncates to 6 significant digits, breaking dump/restore

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: kehan5800(at)gmail(dot)com
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #19744: contrib/seg output truncates to 6 significant digits, breaking dump/restore
Date: 2026-10-05 21:52:49
Message-ID: 1203131.1791237169@sss.pgh.pa.us
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> In practice a 7-significant-digit value is stored exactly

Some of them are, but please don't claim that on the strength of
one test case.

> but printed with 6 digits:

> CREATE EXTENSION seg;
> SELECT '1234567'::seg AS printed,
> seg_lower('1234567'::seg)::float8 AS stored,
> '1234567'::seg::text::seg = '1234567'::seg AS round_trips;

I do not think this is a code bug. The code clearly intends to render
values exactly as long as they're no more than FLT_DIG digits wide,
and it accomplishes that, and it cannot expect to do more because
the underlying storage can't promise more.

It does seem like a documentation bug that the docs are written
as if FLT_DIG were 7. That's not so on any modern platform,
and even when these docs were written I doubt that anything had
that.

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2026-10-06 00:41:47 Re: Spurious curly bracket in "CREATE FUNCTION"/"CREATE PROCEDURE" doc
Previous Message Tom Lane 2026-10-05 21:34:46 Re: BUG #19747: pg_dump does not pin array_nulls, so restore mangles NULL array elements