cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Lerer (JIRA)" <j...@apache.org>
Subject [jira] [Comment Edited] (CASSANDRA-11935) Add support for arithmetic operators
Date Fri, 18 Nov 2016 15:15:58 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-11935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15676926#comment-15676926
] 

Benjamin Lerer edited comment on CASSANDRA-11935 at 11/18/16 3:15 PM:
----------------------------------------------------------------------

bq. So 100+50 is now going to be varint math?

No, :-)
If you have {{SELECT 100 + 50 ...}} the result will be an {{int}}. The patch narrow down the
type up to the {{int}} level. If a literal can fit in an {{int}} C* will try to use the {{int}}
type for the litteral. If it cannot fit in an {{int}}, C* will use {{bigint}} or {{varint}}
for the literal value. Depending in which type it can fit in. The output type will then be
the one of the type with the higher precision. If the left operand is fitting in a {{bigint}}
and the right one in an {{int}} the result type will be a {{bigint}}.

The discussion was about the case where you have {{... WHERE pk = 1 + 1}} and where pk is
a {{smallint}} for example.

bq. It's more of a general remark that having intersecting and pretty special rules doesn't
give me the feel of a clean and well understood type system, which give me slight concerns
that some of those rules may prove annoying in future developments.

This rule is at the end of the chain and is only used for operators. By consequence, I hope,
that if at some point, we have a better alternative, we will be able to replace it without
too much difficulties.    


was (Author: blerer):
bq. So 100+50 is now going to be varint math?

No, :-)
If you have {{SELECT 100 + 50 ...}} the result will be an {{int}}. The patch narrow down the
type up to the {{int}} level. If a literal can fit in an {{int}} C* will try to use the {{int}}
type for the litteral. If it cannot fit in an int C* will use {{bigint}} or {{varint}} for
the literal value depending in which type it can fit in. The output type will then be the
one of the type with the higher precision. So if the left operand is fitting in a {{bigint}}
and the right one in an {{int}} the result type will be a {{bigint}}.

The all discussion is about the case where you have {{... WHERE pk = 1 + 1}} and where pk
is a {{smallint}} for example.

bq. It's more of a general remark that having intersecting and pretty special rules doesn't
give me the feel of a clean and well understood type system, which give me slight concerns
that some of those rules may prove annoying in future developments.

This rule is at the end of the chain and is only used for operators. By consequence, I hope
that if, at some point, we have a better alternative, we will be able to replace it without
too much difficulties.    

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

Mime
View raw message