Michael Smith has submitted this change and it was merged. (
http://gerrit.cloudera.org:8080/24793 )
Change subject: IMPALA-15338: Calcite planner: Plan a TIMESTAMP literal in a
VALUES row
......................................................................
IMPALA-15338: Calcite planner: Plan a TIMESTAMP literal in a VALUES row
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
The parse error is the original planner's: only Calcite's parser accepts
this statement, and when the Calcite planner refuses it,
Frontend.getTExecRequestWithFallback passes it on as unsupported SQL.
That handoff is separate from the fallback_planner option and happens
with fallback_planner=none too, which is why the failure reads as a
syntax error rather than as a planner refusal.
What the Calcite planner refuses is the literal.
ImpalaValuesRel.getValuesExprs converts each literal of a VALUES row
twice: RexLiteralConverter builds a cast from the literal's text and has
the backend fold it, which is where the TimestampLiteral comes from, and
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.
Skip the second conversion when the literal is a timestamp that already
carries the declared type. Only a timestamp takes that path; every other
type still goes through createFromStr, which is what gives a literal the
column's type when the two differ. Teaching createFromStr about
TIMESTAMP is the other repair, but it would have to fold a cast to build
the value and has no analyzer to fold with.
Add UnionNode.getConstExprLists() so a test can read the constant rows a
union carries. A TIMESTAMP literal reaches thrift as the backend's
sixteen raw bytes, so that list is where its value is still legible.
Testing:
- New CalciteValuesLiteralTest, 5 tests: a timestamp literal in a VALUES
row plans and keeps its nanoseconds; a DATE literal and a cast still
plan; rows of different width keep their own literals. With the change
reverted the two timestamp tests fail with "Literal unsupported:
TIMESTAMP" and the other three stay green.
- New calcite.test case, executed through TestCalcitePlanner: the rows
come back as 2024-01-01 00:02:03.456000000 and
1970-01-01 00:00:01.234567891. With the change reverted it fails with
the syntax error above.
- calcite-planner module suite: no class changed its result.
Assisted-by: claude-opus-5 (Claude Code); gpt-5 (OpenAI Codex)
Change-Id: If8b5eebe9b5fa94066ff2f9410cab799fc6a3497
Reviewed-on: http://gerrit.cloudera.org:8080/24793
Reviewed-by: Steve Carlin <[email protected]>
Tested-by: Michael Smith <[email protected]>
---
M fe/src/main/java/org/apache/impala/planner/UnionNode.java
M
java/calcite-planner/src/main/java/org/apache/impala/calcite/rel/node/ImpalaValuesRel.java
A
java/calcite-planner/src/test/java/org/apache/impala/calcite/service/CalciteValuesLiteralTest.java
M testdata/workloads/functional-query/queries/QueryTest/calcite.test
4 files changed, 210 insertions(+), 0 deletions(-)
Approvals:
Steve Carlin: Looks good to me, approved
Michael Smith: Verified
--
To view, visit http://gerrit.cloudera.org:8080/24793
To unsubscribe, visit http://gerrit.cloudera.org:8080/settings
Gerrit-Project: Impala-ASF
Gerrit-Branch: master
Gerrit-MessageType: merged
Gerrit-Change-Id: If8b5eebe9b5fa94066ff2f9410cab799fc6a3497
Gerrit-Change-Number: 24793
Gerrit-PatchSet: 6
Gerrit-Owner: Aleksandr Efimov <[email protected]>
Gerrit-Reviewer: Aleksandr Efimov <[email protected]>
Gerrit-Reviewer: Aman Sinha <[email protected]>
Gerrit-Reviewer: Impala Public Jenkins <[email protected]>
Gerrit-Reviewer: Michael Smith <[email protected]>
Gerrit-Reviewer: Steve Carlin <[email protected]>
