github-actions[bot] commented on code in PR #64026:
URL: https://github.com/apache/doris/pull/64026#discussion_r3340422918


##########
fe/fe-core/src/main/java/org/apache/doris/catalog/PartitionKey.java:
##########
@@ -118,15 +109,7 @@ public static PartitionKey 
createPartitionKey(List<PartitionValue> keys, List<Co
         Preconditions.checkArgument(keys.size() <= columns.size());
         int i;
         for (i = 0; i < keys.size(); ++i) {
-            Type keyType = columns.get(i).getType();
-            // If column type is datatime and key type is date, we should 
convert date to datetime.
-            // if it's max value, no need to parse.
-            if (!keys.get(i).isMax() && (keyType.isDatetime() || 
keyType.isDatetimeV2() || keyType.isTimeStampTz())) {
-                Literal dateTimeLiteral = 
getDateTimeLiteral(keys.get(i).getStringValue(), keyType);
-                partitionKey.keys.add(dateTimeLiteral.toLegacyLiteral());
-            } else {
-                partitionKey.keys.add(keys.get(i).getValue(keyType));
-            }
+            partitionKey.keys.add(keys.get(i).getValue());
             partitionKey.types.add(columns.get(i).getDataType());

Review Comment:
   This now stores the literal exactly as supplied by `PartitionValue`, but 
several constructors feeding this path still use 
`LiteralExprUtils.createLiteral(value, columnType)`, which does not always 
assign the requested column type. For example, `DOUBLE` values are built with 
`new FloatLiteral(value)` and may keep type `FLOAT`, and decimal values are 
built by `DecimalLiteralUtils.create(value)` with an inferred precision/scale 
rather than the partition column's decimal type. This PR also changed 
`FloatLiteral.compareLiteral`/`DecimalLiteral.compareLiteral` to return `-1` 
unless the literal types are equal, so two keys for the same `DOUBLE` or 
`DECIMAL(10,2)` partition column can compare incorrectly/non-antisymmetrically 
when their inferred literal types differ (for example `1` vs `10.00` for 
decimal, or float-fitting vs double-only values). Range validation, sorting, 
and pruning all rely on `PartitionKey.compareTo`, so this can select the wrong 
partitions or reject/order ranges inco
 rrectly. Please keep the old invariant that the stored key literal is coerced 
to the partition column type (or make `LiteralExprUtils.createLiteral` honor 
the requested floating/decimal type) before relying on exact-type literal 
comparisons.



-- 
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]

Reply via email to