lets-order-some-fries opened a new pull request, #68096:
URL: https://github.com/apache/doris/pull/68096
### What problem does this PR solve?
Related PR: #67008
Problem Summary:
`bindWithOrdinal` decides whether a numeric literal in `GROUP BY` / `ORDER
BY` is a positional
reference or an ordinary constant. It read the ordinal with
`IntegerLikeLiteral.getIntValue()` —
which is `getNumber().intValue()` — and only then asked whether it was
within the select list. That
call truncates a `BIGINT` or `LARGEINT` literal to its low 32 bits, so an
ordinal congruent to a
valid one modulo 2^32 passed a test written to reject it:
```sql
-- t1(col1 date, col2 int)
select col1, count(*) from t1 group by 4294967297; -- 2^32 + 1 -> (int) 1
-> GROUP BY col1
select col1, count(*) from t1 group by 3; -- correctly treated as
a constant
```
4294967297 is not a valid ordinal for a two-item select list, so it should
be treated as a constant
exactly as `3` is. Instead it bound to the first select item and the
statement returned rows. The
`ORDER BY` forms behave the same way — `order by 2, 8589934593` sorts by
`(col2, col1)` where only
`col2` was a real sort key, which changes which rows survive a `LIMIT` over
ties.
`bindWithOrdinal` has three call sites (`GROUP BY`, `ORDER BY` over a set
operation, and `ORDER BY`
in an aggregate query), so all three are affected. The decision is made
entirely in the FE and the
original literal is gone before the BE sees the plan, so nothing downstream
can recover the intended
meaning.
**Fix:** compare the literal at full width, and narrow only inside the
branch where the value has
been proven to lie in `1..selectItems`. `getBigDecimalValue()` is the
accessor to use rather than
`getLongValue()`: `LargeIntLiteral` overrides `getBigDecimalValue` but not
`getLongValue`, so a
long-based test would still mis-bind `group by 18446744073709551617` (2^64 +
1).
This is the same shape as #67008, where a 64-bit `LIMIT`/`OFFSET` was
narrowed before its range check
rather than after.
### Release note
Fixed `GROUP BY` / `ORDER BY` binding the wrong column when the positional
ordinal is a `BIGINT` or
`LARGEINT` literal outside the select-list range.
### Check List (For Author)
- Test
- [x] Unit Test — `BindExpressionTest#testOrdinalIsNotNarrowedTo32Bits`
asserts that an ordinal
which wraps into range is treated the same as one that is plainly out
of range.
- Behavior changed:
- [x] Yes. An out-of-range `BIGINT`/`LARGEINT` ordinal is now treated as
a constant instead of
silently binding to a select item. Ordinals inside the select-list
range are unaffected.
- Does this need documentation?
- [x] No.
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
