Also, we really appreciate when as many contributors as possible test a Release Candidate and participate in the vote process. Calcite test suite does not cover all possible scenarios, so it's not uncommon to find a regression during a vote thanks to a downstream project testing the RC.
On Thu, Nov 6, 2025 at 6:40 PM Julian Hyde <[email protected]> wrote: > > Perhaps there is a different way I can be driving the SQL-to-Rel > conversion > > that avoids the problem? > > Consider contributing your test to Calcite. Then problems like this will > be discovered upstream. > > > > On Nov 6, 2025, at 10:35 AM, Mark Lewis <[email protected]> > wrote: > > > > I am seeing a regression in Calcite 1.41.0 on a SQL UPDATE call that > worked in Calcite 1.40.0. For example, using the TPC-DS schema, the > following query: > > > > UPDATE customer SET c_first_name = 'Alice' WHERE c_customer_sk = > 'some_key' > > > > fails with: > > > > java.lang.AssertionError: Unexpected select list size. Select list > should contain both target table columns and set expressions > > at > org.apache.calcite.sql2rel.SqlToRelConverter.convertUpdate(SqlToRelConverter.java:4472) > > at > org.apache.calcite.sql2rel.SqlToRelConverter.convertQueryRecursive(SqlToRelConverter.java:3997) > > at > org.apache.calcite.sql2rel.SqlToRelConverter.convertQuery(SqlToRelConverter.java:631) > > > > It is failing on this check, introduced in commit > 95350ed1a449bbb2f008fcf2b704544e7d95c410: > > > > > https://github.com/apache/calcite/blob/42ff295d6e28672a2ad81b1c30abfbdf44544212/core/src/main/java/org/apache/calcite/sql2rel/SqlToRelConverter.java#L4469-L4475 > > > > If I take the current state of the Calcite main branch (which also > exhibits the same failure) and revert commit > 95350ed1a449bbb2f008fcf2b704544e7d95c410, the resulting code allows the SQL > UPDATE above to run successfully. > > > > Looking in the debugger t the failing case, the SqlNode passed into > SqlRelConverter.convertQuery() (with needsValidation=true, top=true) > contains: > > > > UPDATE `CUSTOMER` SET `C_FIRST_NAME` = 'Alice' > > WHERE `C_CUSTOMER_SK` = 'some_key' > > > > The sourceSelect for the SqlNode is null. Once execution passes the line: > > > > query = validator().validate(query); > > > > The SqlNode (query) has a sourceSelect of: > > > > SELECT *, CAST('Alice' AS CHAR(16) CHARACTER SET `ISO-8859-1`) AS > `EXPR$0` > > FROM `CUSTOMER` > > WHERE `CUSTOMER`.`C_CUSTOMER_SK` = CAST('some_key' AS BIGINT) > > > > This means that its selectList has size 2. When it reaches the check > linked above, this size is expected to equal the sum of the targetTable > rowType fieldCount (18) and call sourceExpressionList size (1). 2 != 19 so > the assertion fails. > > > > Should I open a new Jira and add this information? > > > > Perhaps there is a different way I can be driving the SQL-to-Rel > conversion that avoids the problem? I notice some UPDATE unit tests > included with the commit that introduces the problem pass. A (very) quick > glance at these cases suggests that the query hitting the assertion has > been expanded so that the SELECT includes all the target column names > rather than '*', allowing the assertion check to pass. I don't know why. > >
