[
https://issues.apache.org/jira/browse/CALCITE-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150295#comment-17150295
]
Ruben Q L commented on CALCITE-4085:
------------------------------------
I would be in favor of a minimum agreement with the current status of the PR
(i.e. changes in SqlDotOperator, SqlItemOperator, AliasNamespace). Even if it
is not optimal [~dwysakowicz], it would be an improvement for you since you
would not need to copy-and-edit these classes.
I am afraid that going beyond that can lead to some relevant backwards
compatibility issues (I don't know all the different projects using Calcite,
but I can confirm that I am working on one which "uses the structured types and
depend on the current behavior").
Regarding the structured type vs row discussion, I have no idea what the
difference between them might be in terms of SQL standard, but I have the
impression that in Calcite we have used both concepts interchangeably.
> Improve nullability support for fields of structured type
> ---------------------------------------------------------
>
> Key: CALCITE-4085
> URL: https://issues.apache.org/jira/browse/CALCITE-4085
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: Dawid Wysakowicz
> Assignee: Dawid Wysakowicz
> Priority: Major
> Time Spent: 20m
> Remaining Estimate: 0h
>
> As discussed in
> https://lists.apache.org/thread.html/r602ac95fff23dd1ef974fb396df7be061ab861384ec42f5c57ce0bc2%40%3Cdev.calcite.apache.org%3E
> I would like to change the way a type of a field of a record is derived at
> couple of locations. This helps frameworks such as Apache Flink to build
> support for nullable records with not null fields.
> I suggest to change:
> * SqlDotOperator#deriveType
> * SqlItemOperator#inferReturnType
> * AliasNamespace#validateImpl
> * RexBuilder#makeFieldAccessInternal
> * SqlValidatorImpl.DeriveTypeVisitor#visit(SqlIdentifier)
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
