I attempted to construct TPC-DS tables and data using WITH clauses in a test[1], but I'm uncertain if it can simulate the query scenario properly. I selected q80 for verification and didn't reproduce the error mentioned in the email. As Mihai mentioned, Calcite has many configurations. Could it be that certain configurations are causing the issue? Therefore, it would be best to provide a reproducible test case based on Calcite's current code to facilitate problem analysis.
[1] https://github.com/apache/calcite/pull/4582 在 2025-10-16 00:03:37，"Ruben Q L" <[email protected]> 写道： >Definitely looks like a blocker. >As others have said, we would need a Jira ticket and, ideally, a >minimalistic unit test reproducing the issue. > > >On Wed, Oct 15, 2025 at 4:36 PM Mihai Budiu <[email protected]> wrote: > >> Sounds like a blocking problem. >> >> Can you provide a reproduction? Calcite has many configuration settings. >> In our tests we compile TPCDS without issues, but our configuration is not >> the standard one. >> >> Mihai >> >> >> >> ________________________________ >> From: 我 <[email protected]> >> Sent: Wednesday, October 15, 2025 8:34 AM >> To: dev <[email protected]> >> Subject: Re: Regression in Calcite 1.41.0 >> >> Could you log this issue in Jira? It would be even better if you could >> also provide a minimal test case! >> >> Best, >> Zhen Chen >> >> >> >> ---- Replied Message ---- >> | From | Mark Lewis<[email protected]> | >> | Date | 10/15/2025 22:36 | >> | To | [email protected] | >> | Cc | | >> | Subject | Regression in Calcite 1.41.0 | >> Hi community, >> >> I am making use of the Calcite SQLParser and SQLToRelSqlToRelConverter to >> convert SQL statements from the TPC-DS benchmark suite. In preparation to >> adopt the forthcoming Calcite 1.41.0, I tried using a version of Calcite I >> built locally from the current development codebase. I see failures that >> did not exist with Calcite 1.40.0 on TPC-DS queries 40, 67 and 80; all on >> CASE statements, with the underlying failure in >> SqlValidatorImpl.getValidatedNodeType(): >> >> Query 40 fails on: >> >> CASE WHEN `CR_REFUNDED_CASH` IS NOT NULL THEN `CR_REFUNDED_CASH` ELSE 0 END >> >> with the underlying error: >> >> java.lang.UnsupportedOperationException: class >> org.apache.calcite.sql.SqlBasicCall: `CR_REFUNDED_CASH` >> >> Query 67 fails on: >> >> CASE WHEN `SS_SALES_PRICE` * `SS_QUANTITY` IS NOT NULL THEN >> `SS_SALES_PRICE` * `SS_QUANTITY` ELSE 0 END >> >> with the underlying error: >> >> java.lang.UnsupportedOperationException: class >> org.apache.calcite.sql.SqlBasicCall: `SS_SALES_PRICE` * `SS_QUANTITY` >> >> Query 80 fails on: >> >> CASE WHEN `SR_RETURN_AMT` IS NOT NULL THEN `SR_RETURN_AMT` ELSE 0 END >> >> with the underlying error: >> >> ava.lang.UnsupportedOperationException: class >> org.apache.calcite.sql.SqlBasicCall: `SR_RETURN_AMT` >> >> This regression appears to be introduced in commit >> 12e7d621bbb19aa32cb45329cb84532115037b7a ([CALCITE-7044] Add internal >> operator CAST NOT NULL to enhance rewrite COALESCE operator). Since that >> commit, the SqlNode kind at the point of failure in each case has become >> SqlBasicCall with a CAST NOT NULL operator, and no node type is identified, >> which is a failure condition. >> >> Regards, >> >> Mark. >>
