soin08 commented on PR #28982:
URL: https://github.com/apache/flink/pull/28982#issuecomment-5567102570

   This fixes two cases where converting numeric literals to the key type could 
produce an incorrect pushed-down filter.
   
   First, `widenToKeyType` previously used `Number.longValue()` for BIGINT 
keys. This conversion silently truncates fractional values and wraps values 
outside the `long` range. For example:
   
   - `key < 1.5` was pushed as `key < 1`, incorrectly removing `key = 1`.
   - `key >= 1.5` was pushed as `key >= 1`, incorrectly adding `key = 1`.
   - A bound such as `10^30` could wrap to an unrelated `long` value.
   
   Second, converting an integral FLOAT or DOUBLE literal to one exact BIGINT 
bound is not always safe. When a BIGINT key is compared with a FLOAT or DOUBLE 
literal, SQL coerces the BIGINT operand to an approximate numeric type. At 
large magnitudes, adjacent BIGINT values can then round to the same value. For 
example:
   
   - `16777217L = 16777216f` is true, but pushing `key = 16777216L` omits 
`16777217L`.
   - `9007199254740993L > 9007199254740992d` is false, but pushing `key > 
9007199254740992L` incorrectly includes it.
   
   The fix uses `BigDecimal.longValueExact()` for BIGINT bounds, rejecting 
fractional, non-finite, and out-of-range literals. It also rejects FLOAT 
literals at `abs(value) >= 2^24` and DOUBLE literals at `abs(value) >= 2^53`, 
where integer aliasing becomes possible. Rejected predicates remain in the 
query and are evaluated using the original SQL semantics.
   
   For DOUBLE keys, finite numeric literals are converted to DOUBLE because SQL 
applies the same conversion to the literal. Tests cover fractional and 
out-of-range values, NaN and infinity, positive and negative precision 
boundaries, equality and range predicates, and values immediately below the 
boundaries that remain safe to push.
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: [email protected]

For queries about this service, please contact Infrastructure at:
[email protected]

Reply via email to