Dwrite commented on code in PR #4339:
URL: https://github.com/apache/calcite/pull/4339#discussion_r2217289834
##########
core/src/main/java/org/apache/calcite/sql/fun/SqlStdOperatorTable.java:
##########
@@ -1298,6 +1298,19 @@ public class SqlStdOperatorTable extends
ReflectiveSqlOperatorTable {
SqlBasicFunction.create("BITXOR", SqlKind.BITXOR,
ReturnTypes.LARGEST_INT_OR_FIRST_NON_NULL,
OperandTypes.INTEGER_INTEGER.or(OperandTypes.BINARY_BINARY));
+ /**
+ * <code>{@code ^}</code> operator.
+ */
+ public static final SqlBinaryOperator BITXOR_OPERATOR =
+ new SqlBinaryOperator(
+ "^",
+ SqlKind.BITXOR,
+ 40, // Precedence between addition (40) and multiplication
(60)
+ true,
+ ReturnTypes.LARGEST_INT_OR_FIRST_NON_NULL, // Returns same type as
inputs when nullable
Review Comment:
Thanks for raising this — great point.
You're right that FIRST_NON_NULL can be a bit ambiguous. My understanding is
that LARGEST_INT_OR_FIRST_NON_NULL behaves like:
If both inputs are integer types (including unsigned ones), it returns the
"largest" type that can hold both.
If either is NULL, and inference is based on that input alone, it falls back
to the type of the first non-null argument.
It's a safeguard when type coercion is disabled or incomplete.
In theory, with coercion enabled, inputs should be normalized to the same
type (e.g., INTEGER ^ BIGINT becomes BIGINT ^ BIGINT). But when coercion is
off, this return type inference helps prevent type mismatch errors and makes
the behavior consistent for combinations like UByte ^ Integer, which we've
added support for.
Also, I’ve updated the comment to make this behavior clearer in the code.
That said, I agree this return type logic may benefit from being aligned
more closely with arithmetic rules. If there’s a more precise or canonical way
to represent this (e.g., a custom inference rule or a cleaned-up version of
LARGEST_INT_OR_FIRST_NON_NULL), I’d be happy to experiment with it.
Let me know if you’d prefer I try that here or in a follow-up.
--
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]
