Description: Today, MAP subscript access with a floating-point key (e.g., map[0.1]) silently executes. The optimizer skips
subfield pruning for these keys (#1087), but the query still runs and returns results that may be surprising
due to IEEE 754 semantics:
- 0.1 + 0.2 != 0.3 (rounding)
- NaN != NaN
- -0.0 == +0.0
Rather than optimizing this path, we should fail these queries with a clear error explaining why
floating-point equality is unreliable.
Relevant code:
Context: The skip in #1087 was an intentional conservative fix to avoid a crash on non-integer key types, matching Presto Java's behavior (SubfieldExtractor silently skips float keys). Queries return correct results — the only cost today is a missed read optimization.
The preferred direction is to reject these queries outright rather than silently allow unreliable equality semantics.
Description: Today, MAP subscript access with a floating-point key (e.g., map[0.1]) silently executes. The optimizer skips
subfield pruning for these keys (#1087), but the query still runs and returns results that may be surprising
due to IEEE 754 semantics:
Rather than optimizing this path, we should fail these queries with a clear error explaining why
floating-point equality is unreliable.
Relevant code:
pruning for non-integer/non-string keys
float key types
Context: The skip in #1087 was an intentional conservative fix to avoid a crash on non-integer key types, matching Presto Java's behavior (SubfieldExtractor silently skips float keys). Queries return correct results — the only cost today is a missed read optimization.
The preferred direction is to reject these queries outright rather than silently allow unreliable equality semantics.