[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15311907#comment-15311907
]
Sylvain Lebresne commented on CASSANDRA-11935:
----------------------------------------------
Ok, I guess I'm more unsure about having implicit conversions by itself than
the fact of having operator on different types, which I agree is convenient.
Basically, we can get the same effect by having many overloads of each operator
for every type combination we think is reasonable. It's admittedly a bit
brute-force, but we can likely generate most of the combinations so that it's
not that unwieldy in practice. And I'm not even saying it's better than
implicit conversions, I just want us to carefully weight every options.
Because implicit conversions is not imo a minor detail. If we introduce them,
it'll have to work everywhere, and it _will_ end up implicitly converting stuff
between different storage format. For instance, that would mean we'll start
accepting things like {{WHERE c = (int)?}} when {{c}} is a {{bigint}}. Which,
all other thing being equal, does feel like the user made a slight mistake by
casting to the wrong type, and telling him feels nice to me. Maybe implicit
conversions are still worth it, but as said above, we can get the convenience
in other ways too so it's at least worth discussing.
I'm also not as readily optimistic about implicit conversions being easy to
add. Again, you will have to convert the underlying byte buffers, but I don't
see a clear place in the current code where you could "inject" that (and have
it work everywhere).
Overall, I'd have a clear preference for just adding the overloads we want for
operators as far as this ticket is concerned, because it can be done without
any particular addition to the CQL type system, it's simple (if not elegant for
some definition of elegance), and it doesn't forbid adding implicit conversions
later. And we can consider implicit conversions in parallel, but that's imo a
separate ticket where we should weight the pros and cons for the overall
system, since again, implicit conversions will not be limited to operators.
> 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)
