[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15676457#comment-15676457
]
Sylvain Lebresne commented on CASSANDRA-11935:
----------------------------------------------
bq. It would work for {{i = 100 + 50}} but not for {{SELECT 100 + 50}} where we
will get an error like: {{Ambiguous '+' operation: use type casts to
disambiguate}}.
Honestly, if that's the only issue, I think it'd be fairly acceptable. {{SELECT
100 + 50}} is kind of useless (CQL is not meant to be a calculator) so having
to explicit the return type you want is imo fine (it's not crazy to ask the
user which format it wants that returned since there is multiple valid
options). And forcing an explicit cast in that case doesn't even forbid us to
improve later if we really really want.
bq. In such a case, I believe that we should just pick the operation with the
same argument types than the return type.
It's a somewhat random rule though imo. It's not a terribly general (it might
vaguely make sense for operators, but I don't think it particuarly does for
function in general) and that somewhat conflict with the "prefered type" choice
in some cases on principle.
In general, I think it's not a good thing to have too many special cases for
the function resolution mechanism (simple regular rules are always better in my
experience) and I fear doing so could lead to unexpected issue/difficulties in
the future, so I still would prefer "just" adding more overloads. I know there
is a concern on the memory footprint of those overloads, but have we even
measured that overhead before worrying (it's easy to do and it's fixed)? And
even if it's non negligeable, I suspect we could very well reduce that
overhead, it's largely an implementation detail.
bq. For the {{preferedType}} I still believe that we should stop at {{int}} for
integer to minimize the risk of overflow issues in the selection part.
I can live with that (if I'm being honest, I think I'm a bit umconfortable with
the {{preferedType}} concept in the first place, but I don't a simple good
alternative to suggest either).
> 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)
