Details

    • Type: Bug
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.2.0-incubating
    • Component/s: None
    • Labels:
      None

      Description

      Calcite uses SQL "any" type internally, when the type of an Rex expression is not known precisely. By its name, "any" could mean nullable type, or non-nullable type. Therefore, it makes sense to create SQL "any" type as nullable type.

      However, in the Calcite code, the nullability of "any" type is not set consistently. For example, the SqlItemOperator would set "any" as nullable, while SqlUnresolvedFunction will set "any" as non-nullable.

      SQL "any" type is used extensively in Schema-less system like Drill, since the exact SQL type would be determined in run-time only. Having an inconsistent nullability through Calcite library will cause issues for a schema-less system.

        Activity

        Hide
        julianhyde Julian Hyde added a comment -

        Resolved in release 1.2.0-incubating (2015-04-16)

        Show
        julianhyde Julian Hyde added a comment - Resolved in release 1.2.0-incubating (2015-04-16)
        Show
        julianhyde Julian Hyde added a comment - Fixed in http://git-wip-us.apache.org/repos/asf/incubator-calcite/commit/a00e4521 .
        Hide
        jni Jinfeng Ni added a comment -

        Right. That's what my patch is doing : make sure "any" type is created as nullable, in stead of non-nullable in SqlUnresolvedFunction.

        Probably, the title of this JIRA is not precise. It should be "SQL any type should be created as nullable in various places when no nullability information is known". It's not the problem of ReldataTypeFactory. RelDataTypeFactory has the capacity to create either nullabe or not nullable ANY type.

        Show
        jni Jinfeng Ni added a comment - Right. That's what my patch is doing : make sure "any" type is created as nullable, in stead of non-nullable in SqlUnresolvedFunction. Probably, the title of this JIRA is not precise. It should be "SQL any type should be created as nullable in various places when no nullability information is known". It's not the problem of ReldataTypeFactory. RelDataTypeFactory has the capacity to create either nullabe or not nullable ANY type.
        Hide
        julianhyde Julian Hyde added a comment -

        Because there is a bug in SqlUnresolvedFunction.inferReturnType. RelDataTypeFactory is doing what was asked of it.

        Show
        julianhyde Julian Hyde added a comment - Because there is a bug in SqlUnresolvedFunction.inferReturnType. RelDataTypeFactory is doing what was asked of it.
        Hide
        jni Jinfeng Ni added a comment -

        ANY NOT NULL is possible, only when we know the possible types presented by "ANY" all are NOT NULLable. If we do not have such knowledge, it does not make sense to create a ANY NOT NULL type, to represent possibly NULLABLE types.

        For instance, why does SqlItemOperator would return ANY NULL, while SqlUnresolvedFunction would return ANY NOT NULL?

        Show
        jni Jinfeng Ni added a comment - ANY NOT NULL is possible, only when we know the possible types presented by "ANY" all are NOT NULLable. If we do not have such knowledge, it does not make sense to create a ANY NOT NULL type, to represent possibly NULLABLE types. For instance, why does SqlItemOperator would return ANY NULL, while SqlUnresolvedFunction would return ANY NOT NULL?
        Hide
        julianhyde Julian Hyde added a comment -

        Are you saying that ANY NOT NULL is not possible? If so I disagree. Just like any type, ANY may or may not have a NOT NULL constraint attached.

        I don't think that ANY needs to be treated radically differently by RelDataTypeFactory. I think we just need more tests for expressions involving ANY (or ANY NOT NULL) arguments.

        Show
        julianhyde Julian Hyde added a comment - Are you saying that ANY NOT NULL is not possible? If so I disagree. Just like any type, ANY may or may not have a NOT NULL constraint attached. I don't think that ANY needs to be treated radically differently by RelDataTypeFactory. I think we just need more tests for expressions involving ANY (or ANY NOT NULL) arguments.

          People

          • Assignee:
            julianhyde Julian Hyde
            Reporter:
            jni Jinfeng Ni
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development