Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Dinesh Joshi
Thanks for starting this discussion. I’m definitely in the lossless camp. I’m curious of the performance impact of choosing lossless vs lossy. Dinesh > On Oct 2, 2018, at 10:54 AM, Benedict Elliott Smith > wrote: > > I agree, in broad strokes at least. Interested to hear others’ positions. >

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Rahul Singh
+1 on Postgres approach. In the last 5 years I’ve seen people move from Oracle and SQL server to some variant of Cassandra or Postgres and other new tech is also more likely to support Postgres (Cockroach..) I don’t care either way. It really depends on what you are storing. Rahul Singh Chief E

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Jonathan Haddad
Thanks for bringing this up, it definitely needs to be discussed. Last surprise is difficult here, since all major databases have their own way of doing things and people will just assume that their way is the right way. On that note, some people will be surprised no matter what we do. I'd rathe

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
I agree, in broad strokes at least. Interested to hear others’ positions. > On 2 Oct 2018, at 16:44, Ariel Weisberg wrote: > > Hi, > > I think overflow and the role of widening conversions are pretty linked so > I'll continue to inject that into this discussion. Also overflow is much > wor

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Ariel Weisberg
Hi, I think overflow and the role of widening conversions are pretty linked so I'll continue to inject that into this discussion. Also overflow is much worse since most applications won't be impacted by a loss of precision when an expression involves an int and float, but will care quite a bit

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
This (overflow) is an excellent point, but this also affects aggregations which were introduced a long time ago. They already inherit Java semantics for all of the relevant types (silent wrap around). We probably want to be consistent, meaning either changing aggregations (which incurs a cost

Re: Implicit Casts for Arithmetic Operators

2018-10-02 Thread Ariel Weisberg
Hi, I think we should decide based on what is least surprising as you mention, but isn't overridden by some other concern. It seems to me the priorities are * Correctness * Performance * User visible complexity * Developer visible complexity Defaulting to silent implicit data loss is not ideal

Implicit Casts for Arithmetic Operators

2018-10-02 Thread Benedict Elliott Smith
CASSANDRA-11935 introduced arithmetic operators, and alongside these came implicit casts for their operands. There is a semantic decision to be made, and I think the project would do well to explicitly raise this kind of question for wider input before release, since the project is bound by the