Because it may have different representations of equal numbers, the decimal type has some strange behaviour when it is used as a key anywhere in Cassandra.
For example, when used as a partition key we can't find a row for 3.0 when looking for 3. If we insert a row in a wide partition with clustering 3 and update it with 3.0, queries for it will nondeterministically choose which of the two versions to return. When indexing decimals, legacy indexes can lose values that would be found with ALLOW_FILTERING. See https://issues.apache.org/jira/browse/CASSANDRA-21856 for further examples. Generally, allowing decimals to be used as keys in non-normalized form is asking for trouble. How would the community feel about implementing normalization in the CQL processing code, so that decimals are normalized when they enter the system? If we implement this, should we apply it to regular columns (where the behaviour is well defined, you get what you have inserted) and let the index normalize? Should we introduce a flag to switch the behaviour for partition keys, where legacy data might become unreachable as a result of normalization? Or should we ditch decimals as keys altogether? Switch to a new decimal type with (user-specified) fixed precision? Regards, Branimir
