[
https://issues.apache.org/jira/browse/CALCITE-7457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitry Sysolyatin updated CALCITE-7457:
---------------------------------------
Summary: VALUES and SELECT produce different validation results for the
same expression (was: Top-level VALUES and SELECT produce different validation
results for the same expression)
> VALUES and SELECT produce different validation results for the same expression
> ------------------------------------------------------------------------------
>
> Key: CALCITE-7457
> URL: https://issues.apache.org/jira/browse/CALCITE-7457
> Project: Calcite
> Issue Type: Bug
> Components: core
> Affects Versions: 1.41.0
> Reporter: Dmitry Sysolyatin
> Assignee: Dmitry Sysolyatin
> Priority: Major
> Labels: pull-request-available
>
> While working on CALCITE-7269, I encountered an issue that is somewhat of a
> blocker for me, as the code paths differ: top-level validation for VALUES and
> SELECT behaves inconsistently.
> Test cases:
> {code:java}
> @Test void testSelectVsValuesValidation() {
> // SELECT: inferUnknownTypes runs, FIRST_KNOWN infers NULL as
> // DECIMAL(2,1) and caches it via setValidatedNodeType. deriveType
> // for NULL is never called (type already cached by inference).
> // Result: DECIMAL(2,1) + DECIMAL(2,1) = DECIMAL(3,1).
> sql("select 1.0 + NULL from (values (0)) as t(x)")
> .columnType("DECIMAL(3, 1)");
> // VALUES: inferUnknownTypes does NOT run for top-level VALUES.
> // deriveType for NULL returns BasicSqlType with sqlType with
> SqlTypeName.NULL. The + operator
> // treats DECIMAL(2,1) + NULL as DECIMAL(2,1) since NULL does not
> // affect precision.
> expr("1.0 + NULL")
> .columnType("DECIMAL(2, 1)");
> // SELECT: inferUnknownTypes infers ? as INTEGER from FIRST_KNOWN
> sql("select 1 + ? from (values (0)) as t(x)").ok();
> // VALUES: inferUnknownTypes does NOT run, ? stays UNKNOWN,
> // + operator rejects INTEGER + UNKNOWN
> expr("^1 + ?^")
> .fails("(?s).*Cannot apply '\\+' to arguments of type.*");
> // LOCALTIME(NULL) with type coercion disabled:
> // SELECT: inferUnknownTypes rejects NULL before LOCALTIME validates
> sql("select LOCALTIME(^NULL^) from (values (0)) as t(x)")
> .withTypeCoercion(false)
> .fails("(?s).*Illegal use of .NULL.*");
> // VALUES: inferUnknownTypes does NOT run, LOCALTIME's own
> // checkOperandTypes gives a function-specific error
> wholeExpr("LOCALTIME(NULL)")
> .withTypeCoercion(false)
> .fails("(?s).*Argument to function 'LOCALTIME' must not be NULL.*");
> }
> {code}
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
