[
https://issues.apache.org/jira/browse/CALCITE-1150?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15261256#comment-15261256
]
Julian Hyde commented on CALCITE-1150:
--------------------------------------
I know it's a work in progress, but it's looking good. There are a few things
I'd do slightly differently:
* Move SqlSelect.expanded into the validator, maybe in SelectScope. It is best
if validation does not mutate the parse tree. (Yes, I know expansion changes
the select list but don't want to make that hole of technical debt any deeper.)
* RelDataTypes are immutable, and your DynamicRecordType is mutable. I know you
need a "collector". I could accept using a mutable type just during validation,
then switch to an immutable dynamic record type on sql-to-rel. But if the
collector could be in a scope that would be even better.
* Do you really need "*" to be a field in the record type? Is it not sufficient
for "*" to be a field reference?
* How do you plan to represent the row type of {{SELECT * FROM (SELECT * FROM
t1), (SELECT * FROM t2))}}? There are unresolved stars on both sides.
* Given {{RelDataType t}}, I'd prefer {{t.isDynamicStruct()}} to {{t instanceof
DynamicRecordType}}.
* Minor nit-pick: use {{new ArrayList<>()}} rather than
{{Lists.newArrayList()}} for new code.
* Add a sql-to-rel test {{SELECT * FROM nonDynamicTable WHERE EXISTS (SELECT *
FROM dynamicTable)}}. The select clause of an EXISTS sub-query should always be
ignored.
> Create the a new DynamicRecordType, avoiding star expansion when working with
> this type
> ---------------------------------------------------------------------------------------
>
> Key: CALCITE-1150
> URL: https://issues.apache.org/jira/browse/CALCITE-1150
> Project: Calcite
> Issue Type: Improvement
> Reporter: Jacques Nadeau
> Assignee: Julian Hyde
>
> DynamicRecordType can be used to leverage user-provided field implications to
> avoid schema analysis until execution.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
