[
https://issues.apache.org/jira/browse/CALCITE-4872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450678#comment-17450678
]
Will Noble commented on CALCITE-4872:
-------------------------------------
You say "Add a row to 'Data types' table in reference.md. In a paragraph below,
explain that UNKNOWN is not available from SQL, and what are its uses and
quirks," but in that table there already exists a line that looks like this:
| ANY | A value of an unknown type |
So it seems like maybe we should be using ANY instead of UNKNOWN, though
apparently there is a difference in behavior between ANY and UNKNOWN where
Calcite's SQL writer may insert explicit casts to ANY which would be
undesirable. I would propose we set the expectations for ANY and UNKNOWN as
follows:
ANY: a value of an explicitly unknown type, such that Calcite may insert casts
to ANY as appropriate to ensure type consistency
UNKNOWN: a value of an implicitly unknown type, where Calcite should avoid any
sort of type manipulation and just hope that types just work out. Use at own
risk.
> UNKNOWN SqlTypeName erroneously treated as NULL
> -----------------------------------------------
>
> Key: CALCITE-4872
> URL: https://issues.apache.org/jira/browse/CALCITE-4872
> Project: Calcite
> Issue Type: Bug
> Components: core
> Reporter: Will Noble
> Assignee: Will Noble
> Priority: Major
> Labels: pull-request-available
> Fix For: 1.29.0
>
> Time Spent: 2h
> Remaining Estimate: 0h
>
> Call {{createWithNullability}} on an {{UnknownSqlType}} currently returns a
> {{NULL}} type. Furthermore, it's impossible to cast to unknown types,
> according to {{SqlTypeUtil.canCastFrom}}. This introduces a new
> {{SqlTypeName}} -- {{UNKNOWN}} -- which behaves like {{NULL}} in all ways
> except that it's no longer actually equal to {{NULL}}, and can always be cast
> to.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
