[
https://issues.apache.org/jira/browse/CALCITE-6275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17820199#comment-17820199
]
Julian Hyde commented on CALCITE-6275:
--------------------------------------
In standard SQL, I don't think that NOT NULL is strictly part of the data type
(unlike say Kotlin). It is a constraint on the column that uses that data type.
These days, most of us agree that Kotlin got it right but prepare for it to get
messy if try to impose that order on SQL.
I also recall that a SQL record {{(a, b)}} is deemed to be NULL if and only if
a and b are both null.
> Parser for data types ignores element nullability in collections
> ----------------------------------------------------------------
>
> Key: CALCITE-6275
> URL: https://issues.apache.org/jira/browse/CALCITE-6275
> Project: Calcite
> Issue Type: Bug
> Components: core, server
> Affects Versions: 1.36.0
> Reporter: Mihai Budiu
> Priority: Major
> Labels: pull-request-available
>
> The parser (Parser.jj) has this production rule for DataType:
> {code}
> // Type name with optional scale and precision.
> SqlDataTypeSpec DataType() :
> {
> SqlTypeNameSpec typeName;
> final Span s;
> }
> {
> typeName = TypeName() {
> s = Span.of(typeName.getParserPos());
> }
> (
> typeName = CollectionsTypeName(typeName)
> )*
> {
> return new SqlDataTypeSpec(typeName,
> s.add(typeName.getParserPos()).pos());
> }
> }
> {code}
> Note that there is no way to specify the nullability for the elements of a
> collection, they are always assumed to be non-null. This is most pertinent
> for the server component, where in DDL one cannot specify a table column of
> type INTEGER ARRAY; one always gets an INTEGER NOT NULL ARRAY instead.
> But note that SqlCollectionTypeNameSpec cannot even represent the nullability
> of the elements' type, it takes a SqlTypeNameSpec instead of a
> SqlDataTypeSpec.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
