[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Implicit Casts for Arithmetic Operators

As far as I can tell we reached a relatively strong consensus that we should implement lossless casts by default?  Does anyone have anything more to add?

Looking at the emails, everyone who participated and expressed a preference was in favour of the “Postgres approach” of upcasting to decimal for mixed float/int operands?

I’d like to get a clear-cut decision on this, so we know what we’re doing for 4.0.  Then hopefully we can move on to a collective decision on Ariel’s concerns about overflow, which I think are also pressing - particularly for tinyint and smallint.  This does also impact implicit casts for mixed integer type operations, but an approach for these will probably fall out of any decision on overflow.

> On 3 Oct 2018, at 11:38, Murukesh Mohanan <murukesh.mohanan@xxxxxxxxx> wrote:
> 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 <benjamin.lerer@xxxxxxxxxxxx>
> 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

To unsubscribe, e-mail: dev-unsubscribe@xxxxxxxxxxxxxxxxxxxx
For additional commands, e-mail: dev-help@xxxxxxxxxxxxxxxxxxxx