[ https://issues.apache.org/jira/browse/CALCITE-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17148266#comment-17148266 ]
Danny Chen commented on CALCITE-4085: ------------------------------------- Can we use the [1] to construct nullable record type with non-nullable fields for the Java type and POJO case ? The code in [1] only takes care the fields nullability but we can extend it to have a record nullability setting. Besides on the backwards compatibility, my main concern is moving the nullability from type factory to all kinds of sql contexts make the logic dispersed and fragile, it is hard to keep it right. And it does not have good sustainability when new sql contexts are introduced, i.e. new syntax or operators. [1] https://github.com/apache/calcite/blob/0769a8b31cbbeb5bca66ade30cf3710523da4aaa/core/src/main/java/org/apache/calcite/rel/type/RelDataTypeFactory.java#L518 > 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)