[
https://issues.apache.org/jira/browse/CALCITE-2464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16720327#comment-16720327
]
Stamatis Zampetakis edited comment on CALCITE-2464 at 12/13/18 3:49 PM:
------------------------------------------------------------------------
Indeed, the section that you found gives a nice explanation. Thanks for sharing!
{quote}I believe that a ROW value is considered null if and only if all of its
fields are null. (This contradicts what I said above.) Can you please confirm
this?
{quote}
I suppose you are refferring to the IS NULL and IS NOT NULL predicates when
they are applied to a row and yes you are right. I put below the respective
extract from the SQL standard (Table 14 <null predicate> semantics). I guess
the example you presented corresponds to line 3 in the table below.
Let R be the <row value predicand> and let V be the value of R.
||Expression||R IS NULL||R IS NOT NULL||NOT R IS NULL||NOT R IS NOT NULL||
|degree 1: null|True|False|False|True|
|degree 1: not null|False|True|True|False|
|degree > 1: all null|True|False|False|True|
|degree > 1: some null|False|False|True|True|
|degree > 1: none null|False|True|True|False|
{quote}If someone declares a column r ROW(x INT NOT NULL, y INT NOT NULL)
should we implicitly add NOT NULL to r?
{quote}
I would say no, because that would forbid setting the column value to null.
{quote}if someone declares r ROW(x INT, y INT) NOT NULL should be implicitly
add NOT NULL to x and y?
{quote}
I would say no, because that would forbid creating a structured type where x or
y is null.
Overall, I don't think it is safe to change the nullability charatecteristic of
the struct based on its attributes neither the opposite.
{quote}
The subject of this case, "Struct types are always not nullable", is ambiguous.
Please change it.
I don't think we need a new method in type factory. You can change the
nullability of the type after it is created.
Can we have a test that executes a query and tests whether a ROW column is
null? E.g. "WHERE address IS NULL", or "WHERE address IS NOT NULL". Also a DDL
test in server's table.iq.
{quote}
OK, for the above.
was (Author: zabetak):
{quote}I believe that a ROW value is considered null if and only if all of its
fields are null. (This contradicts what I said above.) Can you please confirm
this?
{quote}
I suppose you are refferring to the IS NULL and IS NOT NULL predicates when
they are applied to a row and yes you are right. I put below the respective
extract from the SQL standard (Table 14 <null predicate> semantics). I guess
the example you presented corresponds to line 3 in the table below.
Let R be the <row value predicand> and let V be the value of R.
||Expression||R IS NULL||R IS NOT NULL||NOT R IS NULL||NOT R IS NOT NULL||
|degree 1: null|True|False|False|True|
|degree 1: not null|False|True|True|False|
|degree > 1: all null|True|False|False|True|
|degree > 1: some null|False|False|True|True|
|degree > 1: none null|False|True|True|False|
{quote}If someone declares a column r ROW(x INT NOT NULL, y INT NOT NULL)
should we implicitly add NOT NULL to r?
{quote}
I would say no, because that would forbid setting the column value to null.
{quote}if someone declares r ROW(x INT, y INT) NOT NULL should be implicitly
add NOT NULL to x and y?
{quote}
I would say no, because that would forbid creating a structured type where x or
y is null.
Overall, I don't think it is safe to change the nullability charatecteristic of
the struct based on its attributes neither the opposite.
{quote}
The subject of this case, "Struct types are always not nullable", is ambiguous.
Please change it.
I don't think we need a new method in type factory. You can change the
nullability of the type after it is created.
Can we have a test that executes a query and tests whether a ROW column is
null? E.g. "WHERE address IS NULL", or "WHERE address IS NOT NULL". Also a DDL
test in server's table.iq.
{quote}
OK, for the above.
> Struct types are always not nullable
> ------------------------------------
>
> Key: CALCITE-2464
> URL: https://issues.apache.org/jira/browse/CALCITE-2464
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.17.0
> Reporter: Stamatis Zampetakis
> Assignee: Julian Hyde
> Priority: Major
>
> Struct types are always not nullable. This can lead to bugs in many parts of
> Calcite (e.g., expression simplification, optimization, code generation) that
> are considering the nullability of a RelDataType.
> The method
> [isNullable|https://github.com/apache/calcite/blob/3c6b5ec759caadabb67f09d7a4963cc7d9386d0c/core/src/main/java/org/apache/calcite/rel/type/RelRecordType.java#L55]
> in the RelRecordType, which is used to represent a structured type, always
> returns false. The nullability of the RelRecordType should be a parameter in
> the constructor as it is the case for various other RelDataTypes.
> Additionally, the data type cache should also take into account the
> nullability of the type in order to return a correct equivalent.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
