| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | hisanori(dot)kobayashi(dot)bp(at)nttdata(dot)com |
| Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
| Subject: | Re: BUG #16755: A specification or a bug? Digit drop on CAST from DOUBLE PRECISION to NUMERIC. |
| Date: | 2020-12-01 15:24:51 |
| Message-ID: | 1394962.1606836291@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-bugs |
PG Bug reporting form <noreply(at)postgresql(dot)org> writes:
> It would be understandable if the CAST from NUMERIC to DOUBLE PRECISION
> would digit drop, but I don't know if it's a specification or a bug to digit
> drop on CAST from DOUBLE PRECISION to NUMERIC. (translated by DeepL)
float8_numeric() only converts DBL_DIG decimal digits. We have had
discussions in the past about changing that, but so far the answer
has been "no". You have to remember that digits beyond DBL_DIG
are unreliable ... so sometimes this would make things better, but
other times it would make things worse.
If you want something that behaves like the textual display
of float8, you can always do float8value::text::numeric.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2020-12-01 15:58:56 | Re: BUG #16758: create temporary table with the same name loses defaults, indexes |
| Previous Message | Anastasia Lubennikova | 2020-12-01 15:23:55 | Re: BUG #15383: Join Filter cost estimation problem in 10.5 |