[
https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16635208#comment-16635208
]
Benedict edited comment on CASSANDRA-11935 at 10/2/18 9:38 AM:
---------------------------------------------------------------
bq. CQL is strongly typed and it has its consequences good and bad
The only requirement of strong typing here is that the behaviour is well
defined. It could upcast to a type that can store both of the operands, if we
wanted.
This behaviour is obviously database dependent. PostgreSQL, for example,
performs only lossless conversions by default - with the only implicit cast for
numbers being to their equivalent of {{decimal}} (i.e. {{numeric}} -
[link|https://www.postgresql.org/docs/current/static/sql-createcast.html])
For a database, I personally prefer this default behaviour, as it is less
surprising. We don't need extreme efficiency for these operations, since we
are incredibly inefficient elsewhere. The costs of casting and evaluating a
more precise answer are low relative to our other costs, so I don't see the
value proposition of truncating values for the user.
bq. Implementing it this way was a conscious decision.
Ok, but this is a fairly important semantic decision for the project, and you
didn't bring this up for wider discussion. So while you may have intended it,
I think the project as a whole needs to endorse this semantic before we set it
in stone with the 4.0 GA.
was (Author: benedict):
bq. CQL is strongly typed and it has its consequences good and bad
The only requirement of strong typing here is that the behaviour is well
defined. It could upcast to a type that can store both of the operands, if we
wanted.
This behaviour is obviously database dependent. PostgreSQL, for example,
performs only lossless conversions by default - with the only implicit cast for
numbers being to their equivalent of {{decimal}} ({{numeric}})
[link|https://www.postgresql.org/docs/current/static/sql-createcast.html]
For a database, I personally prefer this default behaviour, as it is less
surprising. We don't need extreme efficiency for these operations, since we
are incredibly inefficient elsewhere. The costs of casting and evaluating a
more precise answer are low relative to our other costs, so I don't see the
value proposition of truncating values for the user.
bq. Implementing it this way was a conscious decision.
Ok, but this is a fairly important semantic decision for the project, and you
didn't bring this up for wider discussion. So while you may have intended it,
I think the project as a whole needs to endorse this semantic before we set it
in stone with the 4.0 GA.
> 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
> Priority: Major
> Fix For: 4.0
>
>
> 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
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
