Hi,
Thank you Alvaro, Andres and David.
I tried Andres suggestion in his last email and that seems to work as a work around. Please see below.
SELECT BIG_NUM, FLOOR(BIG_NUM /10000000000.0000000000), BIG_NUM/10000000000.0000000000 from test_table
"3691635539999999999" "369163553" "369163553.9999999999"
"3691635530099999999" "369163553" "369163553.0099999999"
"3691635530999999999" "369163553" "369163553.0999999999"
But should this be a bug? Can their a better support of this, instead of having the query writer to know how many
decimalnumbers to put to get the correct type?
It seems a little awkward and error prone to have to type .0000.... etc?
Thank you all again for the fast response.
Kaleb Akalework
-----Original Message-----
From: Andres Freund <andres@anarazel.de>
Sent: Friday, May 17, 2019 12:24 PM
To: Alvaro Herrera <alvherre@2ndquadrant.com>
Cc: Kaleb Akalework <kaleb.akalework@asg.com>; pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #15812: Select statement of a very big number, with a division operator seems to round up.
*** External email: Verify sender before opening attachments or links ***
Hi,
On 2019-05-17 12:02:11 -0400, Alvaro Herrera wrote:
> On 2019-May-17, PG Bug reporting form wrote:
>
> > create table test_table
> > (
> > REQUEST_UUID varchar(50) not null,
> > BIG_NUM numeric(20,0) not null
> > );
> >
> > INSERT INTO test_table (REQUEST_UUID, BIG_NUM) values ('TEST',
> > 3691635539999999999); INSERT INTO test_table (REQUEST_UUID, BIG_NUM)
> > values('TEST', 3691635530099999999); INSERT INTO test_table
> > (REQUEST_UUID, BIG_NUM) values('TEST', 3691635530999999999);
> >
> > SELECT BIG_NUM, FLOOR(BIG_NUM/10000000000), BIG_NUM/10000000000
> > from test_table;
>
> Well, your column definition has room for zero decimal places, so I'm
> not sure this result is all that surprising. Maybe you should cast
> the column to one that has a few decimal places, say
> select bit_num::numeric(30,10) / 10000000000 from test_table; and
> see whether that helps your case.
Arguably it's less the column's and more the divisor's precision that's the problem. Note that even if big_num were
numeric(i.e. without an implied precision) you'd get the OP's results - the precision is not "widened" to the
appropriatewidth for the max precision needed for the division.
Greetings,
Andres Freund
