[ 
https://issues.apache.org/jira/browse/CALCITE-4085?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17150701#comment-17150701
 ] 

Danny Chen commented on CALCITE-4085:
-------------------------------------

I think we should answer the question for a record type:

Row(A int not null, B varchar(20))

What the "NOT NULL" constraint means for the field A, does it mean 

- 1. it is not null within the row
- 2. or does it mean it is not null when we use it(access it through field 
access, dot or item .etc).

It the answer is 2, current factory does the right thing, if it is 1, we should 
try to preserve the nullability when constructing it.
Since the SQL standard does not allow nullability constraint, i tried OracleL 
here:

{code:sql}
CREATE TYPE address_t AS OBJECT (
   street  VARCHAR2(30),
   city    VARCHAR2(20),
   state   CHAR(2),
   zip     CHAR(5) );

CREATE TABLE customers (
   custid  NUMBER,
   address address_t);

INSERT INTO customers VALUES (1, address_t('101 First', 'Redwood Shores', 'CA', 
'94065'));
INSERT INTO customers VALUES (2, null);
INSERT INTO customers VALUES (3, address_t(null, null, null, null));
{code}

the query:

{code:sql}
select * from customers where address is null;
{code}

outputs:

{code:sql}
-- custid address
-- 2         null
{code}

Even though all the attributes are null for address, the object itself is not 
null.

> 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)

Reply via email to