[
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)
