> 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?
In all the fuzz testing we exclude decimal specifically because this doesn’t exist… so I support it. It’s also not the only type that has this issue; varint does as well. The number 1 as 1 byte or 4 bytes are logically the same but physically not to us… so having a normalization process would help more than just decimal > 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? For consistency it would be good to allow on regular columns. My first thought is you kinda need to opt-in per column as 3.0 and 3 might mean something to your use case (I don’t know what…). This makes me wonder if we should extend the constraints logic to add that pre-processing? CREATE TABLE tbl( pk decimal CHECK NORMALIZE, ck decimal CHECK NORMALIZE, s decimal static CHECK NORMALIZE, r decimal CHECK NORMALIZE, The main issue with this is its opt-in and to your point decimal in PK is unsafe without it (unless you know what you are doing) > On Nov 5, 2026, at 7:11 AM, Aaron <[email protected]> wrote: > > I suppose it makes sense that 3 and 3.0 will generate different tokens. Is > the issue that a user might INSERT a key value of 3, and have it converted to > 3.0 and tokenized as 3.0? But either way, yes, I can see how this is a > problem. > > I'm trying to think about a data modeling scenario where it makes sense to > use DECIMAL as a partition key type, and I just don't see one. Maybe we > should ditch DECIMALs as keys. I suppose though, the way we've been going > lately, is putting a setting in the cassandra.yaml of something like > ALLOW_DECIMALS_AS_KEYS: false, but that's probably overkill. But preventing > the use of DECIMALs as keys feels like the right move here. > > Aaron > > > On Thu, Nov 5, 2026 at 8:50 AM Branimir Lambov via dev > <[email protected] <mailto:[email protected]>> wrote: >> 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
