From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | levi(at)leviaul(dot)com |
Cc: | pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #16919: Unexpected precision loss in NUMERIC type during text cast, math operations |
Date: | 2021-03-10 22:00:08 |
Message-ID: | 2218408.1615413608@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:
> Simple operations on NUMERIC, supposedly an arbitrary-precision type, are
> having unexpected results for me:
> SELECT '12345678901234567890123456789012345678901234567890'::numeric;
> -- expected 12345678901234567890123456789012345678901234567890
> -- got 12345678901234567890123456789012345678900000000000
[ raised eyebrow... ] Works for me:
regression=# SELECT '12345678901234567890123456789012345678901234567890'::numeric;
numeric
----------------------------------------------------
12345678901234567890123456789012345678901234567890
(1 row)
I'm wondering which compiler and what build options you used.
Also, your reference to mpz makes me doubt that this is a stock
version of Postgres, so maybe you just have a home-grown bug.
(There are some arbitrary decisions about precision of the results
of numeric division, as well as the transcendental functions.
But plain addition and multiplication should be exact, and of course
just reading out a literal certainly should be.)
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Levi Aul | 2021-03-11 02:22:59 | Re: BUG #16919: Unexpected precision loss in NUMERIC type during text cast, math operations |
Previous Message | Tom Lane | 2021-03-10 21:51:31 | Re: 12.4 -> 12.5 upgrade, broken CTE query |