gotchasqlMinor
Whats the difference between float and numeric in Postgresql?
Viewed 0 times
postgresqlthenumericfloatwhatsdifferencebetweenand
Problem
Reading the Postgresql docs about the numeric data types
leads me to this question:
why do I get these unexpected results with the data types
For example:
Then run
In this test
Which one is the appropriate data type for precise numeric values like currency or inventory quantities?
leads me to this question:
why do I get these unexpected results with the data types
Float (SQL standard) and Numeric in Postgresql?For example:
CREATE TEMP TABLE testnum (a numeric, b float);
INSERT INTO testnum VALUES (100,100);
INSERT INTO testnum VALUES (9*9*9,9*9*9);
INSERT INTO testnum VALUES (9^9^9,9^9^9);
SELECT (a/3)*3 AS numeric, (b/3) * 3 AS float FROM testnum;
SELECT (a/5)*5 AS numeric, (b/5) * 5 AS float FROM testnum;Then run
SELECT (a/3)*3 AS numeric, (b/3) * 3 AS float FROM testnum;
numeric | float
99.9999999999999999 | 100
729.0000000000000000 | 729In this test
Float looks more accurate than Numeric.Which one is the appropriate data type for precise numeric values like currency or inventory quantities?
Solution
You are falling victim of implicit type casts. When one of the operands is
When one of the operands is
As to
Which one is the appropriate data type for precise numeric values like currency or inventory quantities?
the manual gives you the exact answer you need:
If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead.
What it does not say is that you should control calculations at each step by using explicit type casting and rounding appropriate for your business rules.
numeric and another one integer, the integer operand will be cast to numeric and the result will be numeric. Since numeric has a strictly defined precision, attempting to assign to it a value with infinitely many digits after the decimal point (which 100/3 produces), without rounding, will result in truncation. The same logic applies to multiplication, to which one operand now is not 33.333... (with an infinite sequence of "3"s) that you seem to expect, but rather a defined precision numeric 33.333...3 (a finite sequence of "3"s), which naturally produces 99.999...9 -- a finite sequenceWhen one of the operands is
float and another one integer, the integer operand will be cast to float and the result will be float. Since float has an approximate precision, it is equipped to deal with 33.333... and 99.999... differently, which eventually results in an approximate value of 100.As to
Which one is the appropriate data type for precise numeric values like currency or inventory quantities?
the manual gives you the exact answer you need:
If you require exact storage and calculations (such as for monetary amounts), use the numeric type instead.
What it does not say is that you should control calculations at each step by using explicit type casting and rounding appropriate for your business rules.
Context
StackExchange Database Administrators Q#278828, answer score: 5
Revisions (0)
No revisions yet.