3 ms·
And yet the proper way to handle monetary values has always been to operate on integer values with a predetermined precision. https://stackoverflow.com/questio
by Pamar 9y ago
And yet the proper way to handle monetary values has always been to operate on integer values with a predetermined precision.
https://stackoverflow.com/questions/3730019/why-not-use-double-or-float-to-represent-currency https://stackoverflow.com/questions/3730019/why-not-use-doub...
I can understand the convenience if you are setting up a simple online store, but more complicated cases (like the one in your example) absolutely need a proper handling of decimal values.
- fauigerzigerk 9y agoCan you explain to me what particular cases postgresql's decimal type cannot handle properly _and_ conveniently?
- anarazel 9y ago> Can you explain to me what particular cases postgresql's decimal type cannot handle properly _and_ conveniently? I entirely agree that numeric is a good solution for this case. But to try to answer your question nevertheless: I'd say there is potential for storage density and math performance issues. You really need to have a number of numerics for each row, and a lot of rows to make storage density matter. If you do a lot of aggregates over numerics you definitely can notice the CPU overhead of them over say a plain float. But most of the time that doesn't matter.
- fauigerzigerk 9y agoI agree completely.