[
https://issues.apache.org/jira/browse/CALCITE-4972?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17482065#comment-17482065
]
Julian Hyde commented on CALCITE-4972:
--------------------------------------
Apologies for the confusing advice. I guess we should say "don't squash or
rebase unless the reviewer asks you to". Our intent is to avoid losing the
discussion or forgetting where we were in the review process if contributors do
unnecessary rebases. In this case, the rebase is necessary and may (I fear) be
non-trivial.
> Subfields of array columns containing structs are not qualified in
> getFieldOrigins
> ----------------------------------------------------------------------------------
>
> Key: CALCITE-4972
> URL: https://issues.apache.org/jira/browse/CALCITE-4972
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.28.0
> Reporter: Mark Grey
> Priority: Minor
> Labels: pull-request-available
> Time Spent: 10m
> Remaining Estimate: 0h
>
> Attempting to follow on the [suggestions from Julian in this
> thread|https://lists.apache.org/thread/pdpqtzy5mtzlpdbhwghbty6cj0jgc86l],
> found a potential improvement.
> Given a table schema containing a repeated array of structs and a query
> projecting fields of that struct via UNNEST, the present implementation of
> {{getFieldOrigins}} in {{SqlValidatorImpl}} will return a list representation
> suggesting that the subfield is actually a member of the top level table row
> type.
> For example, when using the [DEPT_NESTED table from the
> MockCatalogReaderSimple|https://github.com/apache/calcite/blob/master/testkit/src/main/java/org/apache/calcite/test/catalog/MockCatalogReaderSimple.java#L152-L159]
> within tests with the following query:
> {code:sql}
> select e.empno from dept_nested, unnest(employees) as e
> {code}
> The return value currently is:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPNO}
> {code}
> Rather than:
> {code:java}
> {CATALOG.SALES.DEPT_NESTED.EMPLOYEES.EMPNO}
> {code}
> No such column {{EMPNO}} exists in the root schema of the DEPT_NESTED table.
> [The javadoc for the method
> |https://github.com/apache/calcite/blob/master/core/src/main/java/org/apache/calcite/sql/validate/SqlValidator.java#L717-L728]however
> suggests that the return from this method should always be four entries
> long, although it would seem this doesn't account for nesting. Is this
> intended behavior, or should {{column}} entry of this list be of variable
> length?
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
