xiangfu0 commented on code in PR #18658:
URL: https://github.com/apache/pinot/pull/18658#discussion_r3348370885
##########
pinot-query-planner/src/main/java/org/apache/pinot/query/planner/logical/RelToPlanNodeConverter.java:
##########
@@ -950,8 +950,17 @@ public static ColumnDataType
convertToColumnDataType(RelDataType relDataType) {
case TINYINT:
case SMALLINT:
case INTEGER:
+ // Calcite 1.41+ (CALCITE-1466) parses unsigned integer types under
BABEL conformance. Pinot has no unsigned
+ // storage, so map each to the narrowest signed type that holds its full
range: UTINYINT (0..2^8-1) and
+ // USMALLINT (0..2^16-1) fit in INT; UINTEGER (0..2^32-1) needs LONG (a
signed INT would wrap values above 2^31).
+ case UTINYINT:
+ case USMALLINT:
return isArray ? ColumnDataType.INT_ARRAY : ColumnDataType.INT;
case BIGINT:
+ case UINTEGER:
+ // UBIGINT (0..2^64-1) has no wider signed type, so values above
Long.MAX_VALUE wrap (two's-complement) - this is
+ // unavoidable and acceptable since Pinot has no unsigned storage type.
+ case UBIGINT:
Review Comment:
Accepting `UBIGINT` here turns `BIGINT UNSIGNED` into a lossy signed `LONG`.
Any value above `Long.MAX_VALUE` will now silently wrap, so this is a
wrong-result regression rather than a harmless type downgrade. Since Pinot
cannot represent the full unsigned 64-bit range, this needs to fail
validation/planning instead of being mapped to `LONG`.
--
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]
