ihuzenko commented on a change in pull request #1374: [CALCITE-3138]
RelStructuredTypeFlattener doesn't restructure ROW type fields
URL: https://github.com/apache/calcite/pull/1374#discussion_r315517950
##########
File path:
core/src/main/java/org/apache/calcite/sql2rel/RelStructuredTypeFlattener.java
##########
@@ -934,7 +968,21 @@ private RexNode flattenComparison(
return conjunction;
}
}
+
+ }
+
+ private int getNewInnerOrdinal(RexNode firstOp, String literalString) {
+ int newInnerOrdinal = 0;
+ for (RelDataTypeField field : firstOp.getType().getFieldList()) {
+ if (literalString.equalsIgnoreCase(field.getName())) {
+ break;
Review comment:
1) Every call to the method is performed only after the check.
```
if (rexCall.op == SqlStdOperatorTable.ITEM
&& rexCall.operands.get(0).getType().isStruct()
&& rexCall.operands.get(1).isA(SqlKind.LITERAL)
&& SqlTypeUtil.inCharFamily(rexCall.operands.get(1).getType())) {
```
So I think it's enough to guarantee that we're looking for inner field
within struct returned by first operand of ITEM.
2) What's actually wrong with matching of first field if iteration is
performed for non flattened struct fields ? There is no threat that some nested
field with same name will come up and match before the desired one. Maybe I
misunderstand you and you're just worried about case insensitive match, then in
my opinion it's unlikely that users will create structs, like ```STRUCT
<aaa:INT, AAA:STRING>``` .
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
[email protected]
With regards,
Apache Git Services
