cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benedict (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
Date Tue, 02 Oct 2018 09:39:00 GMT

    [ 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-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org


Mime
View raw message