| 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
| 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 |