[jira] [Commented] (CASSANDRA-11935) Add support for arithmetic operators

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15650717#comment-15650717 ] 

Sylvain Lebresne commented on CASSANDRA-11935:
----------------------------------------------

bq.  {{c = 1 + 1}} will nearly always require a cast. By consequence, I do not think that we can base our decision on this example.

As of this patch, yes, but that's more a bug than a feature imo. We have the type of {{c}} in this context, so there is no excuse for requiring a cast, and that's exactly why I created CASSANDRA-11946 which would solve that.

bq. In fact most of the relational databases, including ProgreSQL), will convert litterals like 1 to integers.

I'll admit I don't know how other DB type system work, but I strongly believe our type system should have some form of coherence. Let's admit we're ok with a system where literals are always at least {{int}} (in practive, I think it would be a bit of a pain to work with {{tinyint}} and {{smallint}}, but let's assume we're fine with that for a minute): in that case {{c = 2}} shouldn't type-check when {{c}} is a {{tinyint}} and it does (and we cannot change that without breaking backward compatibility). So basically, I just think any system where {{c = 2}} works but {{c = 1 + 1}} doesn't is kind of obviously broken and I prefer not-broken systems :).

bq. On the other hand, I fear that most of the users will be surprise by the result of {{100 + 50}} if we narrow the type of {{100}} and {{50}} to tinyint.

I totally agree in the sense that it's not ok if the value overflows when you do {{i = 100 + 50}} where {{i}} is an {{int}}: you should get {{150}} in that case and we can't have a system that doesn't do that, it's too surprising. That said, I "think" CASSANDRA-11946 also help here, assuming we restrict functions overloads by return type first. In that case, we'd create overloads with same argument types but different return type (so {{tinyint add(tinyint, tinyint)}}, {{int add(tinyint, tinyint)}}, {{bigint add(tinyint, tinyint)}}, etc...) and {{i = 100 + 50}} would use the proper one. If you do {{SELECT 100 + 50}}, we'd use our "prefered type" system to pick the most precise function and the result would be a {{tinyint}} but that's pretty consistent really.

Note that unless I'm missed some subtlety, CASSANDRA-11946 is pretty simple and I'm happy to include it here if it makes sense.

Outside of this problem, the rest of the fixes lgtm, thanks.


> Add support for arithmetic operators
> ------------------------------------
>
>                 Key: CASSANDRA-11935
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-11935
>             Project: Cassandra
>          Issue Type: Sub-task
>          Components: CQL
>            Reporter: Benjamin Lerer
>            Assignee: Benjamin Lerer
>             Fix For: 3.x
>
>
> The goal of this ticket is to add support for arithmetic operators:
> * {{-}}: Change the sign of the argument
> * {{+}}: Addition operator
> * {{-}}: Minus operator
> * {{*}}: Multiplication operator
> * {{/}}: Division operator
> * {{%}}: Modulo operator
> This ticket we should focus on adding operator only for numeric types to keep the scope as small as possible. Dates and string operations will be adressed in follow up tickets.
> The operation precedence should be:
> # {{*}}, {{/}}, {{%}}
> # {{+}}, {{-}}
> Some implicit data conversion should be performed when operations are performed on different types (e.g. double + int).



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)