@Mark, could you please provide more details for reproducibility? (details about your system, Calcite configuration, full stack-trace, etc) Also, if you're not already subscribed to the dev list, I encourage you to do so (as explained in [1]) in order to be up-to-date with this (and other) discussions.
Best, Ruben [1] https://calcite.apache.org/community/#mailing-lists On Wed, Oct 15, 2025 at 5:03 PM Ruben Q L <[email protected]> wrote: > 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. >> >
