silundong commented on code in PR #4877:
URL: https://github.com/apache/calcite/pull/4877#discussion_r3073002861
##########
core/src/main/java/org/apache/calcite/sql/validate/implicit/TypeCoercionImpl.java:
##########
@@ -652,7 +652,23 @@ private boolean coalesceCoercion(SqlCallBinding
callBinding) {
@Override public boolean quantifyOperationCoercion(SqlCallBinding binding) {
final RelDataType type1 = binding.getOperandType(0);
final RelDataType collectionType = binding.getOperandType(1);
- final RelDataType type2 = collectionType.getComponentType();
+ RelDataType type2 = collectionType.getComponentType();
+
+ // Determine whether the right-hand side is a subquery or a collection.
+ final boolean isSubQuery = binding.operand(1) instanceof SqlSelect;
+
+ if (type2 == null) {
+ if (!isSubQuery) {
+ return false;
+ }
+ // Subquery path: derive type2 from the first output column.
Review Comment:
I may have discovered another related issue. As far as I know, For the `<`,
`<=`, `>` and `>=` cases, the row elements are compared left-to-right, stopping
as soon as an unequal or null pair of elements is found (similar to
lexicographic order). Currently, when converting `ROW(a, b) > SOME (SELECT a, b
FROM tbl)`, `SqlToRelConverter` expands the ROW into individual operands in the
RexSubQuery:
```
// SqlCall
ROW(a, b) > SOME (SELECT a, b FROM tbl)
// RexNode
> SOME($1, $2, {
Project(a, b)
Scan(tbl)
})
```
This seems to cause the comparison semantics of ROW to be broken during
subquery removal. Should we perform the following transformation:
```
// SqlCall
ROW(a, b) > SOME (SELECT a, b FROM tbl)
// RexNode
> SOME(ROW($1, $2), {
Project(ROW(a, b))
Scan(tbl)
})
```
--
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]
