[jira] [Updated] (IMPALA-15338) Calcite planner: Fix TIMESTAMP literal conversion in VALUES

["Aleksandr Efimov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IMPALA-15338?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Aleksandr Efimov updated IMPALA-15338:
--------------------------------------
    Summary: Calcite planner: Fix TIMESTAMP literal conversion in VALUES  (was: Calcite planner: a TIMESTAMP literal in a VALUES row fails with a syntax error)

> Calcite planner: Fix TIMESTAMP literal conversion in VALUES
> -----------------------------------------------------------
>
>                 Key: IMPALA-15338
>                 URL: https://issues.apache.org/jira/browse/IMPALA-15338
>             Project: IMPALA
>          Issue Type: Sub-task
>          Components: Frontend
>            Reporter: Aleksandr Efimov
>            Assignee: Aleksandr Efimov
>            Priority: Major
>
> {code}
> set planner=calcite;
> values (timestamp '2024-01-01 00:02:03.456');
> ParseException: Syntax error in line 1:
> values (timestamp '2024-01-01 00:02:03.456')
>         ^
> Encountered: TIMESTAMP
> {code}
> The parse error is the original planner's. Impala's parser has no TIMESTAMP
> literal, so only Calcite's parser accepts this statement; the Calcite planner
> then throws UnsupportedFeatureException("Literal unsupported: TIMESTAMP") and
> Frontend.getTExecRequestWithFallback passes the statement to the original
> planner as unsupported SQL. That handoff is separate from the fallback_planner
> option: it happens with fallback_planner=none too.
> ImpalaValuesRel.getValuesExprs converts each literal of the row twice.
> RexLiteralConverter builds a cast from the literal's text and has the backend
> fold it, which is where the TimestampLiteral comes from; getLiteralExprWithType
> then re-creates that literal from its own text through LiteralExpr.createFromStr,
> to give it the type the column declares. createFromStr has no case for TIMESTAMP
> and throws. The literal already carries that type, so the fix is to skip the
> second conversion for a timestamp.
> The number of fractional digits makes no difference, three fail like nine. Until
> this is fixed, writing the value as a cast works: a cast stays in a projection
> above the row instead of becoming part of the tuple.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

---------------------------------------------------------------------
To unsubscribe, e-mail: issues-all-unsubscribe@impala.apache.org
For additional commands, e-mail: issues-all-help@impala.apache.org