John created CALCITE-5522:
-----------------------------
Summary: DATE_TRUNC: Babel parser behaviour change after update
Key: CALCITE-5522
URL: https://issues.apache.org/jira/browse/CALCITE-5522
Project: Calcite
Issue Type: Bug
Components: babel
Affects Versions: 1.33.0
Reporter: John
Looks like updating to Calcite 1.33.0 changed parsing behavior for DATE_TRUNC.
The following query was parsed successfully with 1.32.0:
{noformat}
SELECT DATE_TRUNC('month', orders.order_date) from orders{noformat}
But with version 1.33.0 it fails with stack trace:
{noformat}
Caused by: org.apache.calcite.sql.parser.SqlParseException: Encountered \".\"
at line 35, column 35.
Was expecting:
\")\" ...
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.convertException(SqlBabelParserImpl.java:412)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.normalizeException(SqlBabelParserImpl.java:158)
at
org.apache.calcite.sql.parser.SqlParser.handleException(SqlParser.java:159)
at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:174)
at company.x.d.Parser.parse(Parser.java:355)
at company.x.d.ProjectContext.lambda$build$4(ProjectContext.java:195)
... 14 common frames omitted
Caused by: org.apache.calcite.sql.parser.babel.ParseException: Encountered
\".\" at line 35, column 35.
Was expecting:
\")\" ...
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.generateParseException(SqlBabelParserImpl.java:37113)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.jj_consume_token(SqlBabelParserImpl.java:36924)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.DateTruncFunctionCall(SqlBabelParserImpl.java:7694)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.BuiltinFunctionCall(SqlBabelParserImpl.java:7022)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.AtomicRowExpression(SqlBabelParserImpl.java:4539)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression3(SqlBabelParserImpl.java:4293)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.AddExpression2b(SqlBabelParserImpl.java:3986)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression2(SqlBabelParserImpl.java:4027)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Expression(SqlBabelParserImpl.java:3959)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SelectExpression(SqlBabelParserImpl.java:2189)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.AddSelectItem(SqlBabelParserImpl.java:2154)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlSelect(SqlBabelParserImpl.java:1462)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.LeafQuery(SqlBabelParserImpl.java:709)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.Query(SqlBabelParserImpl.java:3828)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.ExprOrJoinOrOrderedQuery(SqlBabelParserImpl.java:501)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.ParenthesizedExpression(SqlBabelParserImpl.java:741)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.AddWithItem(SqlBabelParserImpl.java:3924)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.WithList(SqlBabelParserImpl.java:3907)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.QueryOrExpr(SqlBabelParserImpl.java:3800)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.OrderedQueryOrExpr(SqlBabelParserImpl.java:566)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmt(SqlBabelParserImpl.java:1050)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.SqlStmtEof(SqlBabelParserImpl.java:1078)
at
org.apache.calcite.sql.parser.babel.SqlBabelParserImpl.parseSqlStmtEof(SqlBabelParserImpl.java:206)
at org.apache.calcite.sql.parser.SqlParser.parseQuery(SqlParser.java:172)
... 16 common frames omitted
{noformat}
I tried including a custom DATE_TRUNC function in the operator table with
matching operands, but looks like the parser always tries to interpret
*{{{{orders.order_date}}}}* as an interval qualifier?
Looks like the success with 1.32.0 was accidental since CALCITE-5290 aims to
address these kinds of queries. But bringing this to light, in case anyone else
relied on the prior behavior.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
