I think you're conflating two things here. There's the loss resulting from
using some operators, and loss involved in casting. Dividing an integer by
another integer to obtain an integer result can result in loss, but there's
no implicit casting there and no loss due to casting. Casting an integer
to a float can also result in loss. So dividing an integer by a float, for
example, with an implicit cast has an additional avenue for loss: the
implicit cast for the operands so that they're of the same type. I believe
this discussion so far has been about the latter, not the loss from the
operations themselves.
On Wed, 3 Oct 2018 at 18:35 Benjamin Lerer
wrote:
> Hi,
>
> I would like to try to clarify things a bit to help people to understand
> the true complexity of the problem.
>
> The *float *and *double *types are inexact numeric types. Not only at the
> operation level.
>
> If you insert 676543.21 in a *float* column and then read it, you will
> realize that the value has been truncated to 676543.2.
>
> If you want accuracy the only way is to avoid those inexact types.
> Using *decimals
> *during operations will mitigate the problem but will not remove it.
>
>
> I do not recall PostgreSQL behaving has described. If I am not mistaken in
> PostgreSQL *SELECT 3/2* will return *1*. Which is similar to what MS SQL
> server and Oracle do. So all thoses databases will lose precision if you
> are not carefull.
>
> If you truly need precision you can have it by using exact numeric types
> for your data types. Of course it has a cost on performance, memory and
> disk usage.
>
> The advantage of the current approach is that it give you the choice. It is
> up to you to decide what you need for your application. It is also in line
> with the way CQL behave everywhere else.
>
--
Muru
