Skip to content

IGNITE-28852 Fix DML for overloaded binary operators in Calcite engine#13324

Open
tkalkirill wants to merge 2 commits into
masterfrom
ignite-28852
Open

IGNITE-28852 Fix DML for overloaded binary operators in Calcite engine#13324
tkalkirill wants to merge 2 commits into
masterfrom
ignite-28852

Conversation

@tkalkirill

Copy link
Copy Markdown
Contributor

@tkalkirill tkalkirill requested a review from alex-plekhanov July 3, 2026 12:11
SqlValidatorScope scope = getWhereScope(srcSelect);

for (SqlNode expr : call.getSourceExpressionList()) {
deriveType(scope, expr);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Redundant braces

}

/** */
@Test

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Too complicated test. We can reproduce this problem much simplier without any extensions with test like:

    @Test
    public void testDmlIntervalArithmetic() {
        sql("CREATE TABLE test(ts TIMESTAMP)");
        sql("INSERT INTO test VALUES (?)", Timestamp.valueOf("2021-01-01 00:00:01"));
        sql("UPDATE test SET ts = ts - INTERVAL 1 SECOND");
        assertQuery("SELECT * FROM test").returns(Timestamp.valueOf("2021-01-01 00:00:00")).check();
    }

WIth this code we can prove that standard Calcite date arithmetic has the same problem (at least we can easily check it with pure Apache Calcite), report bug to Calcite, and remove our patch later.

@tkalkirill tkalkirill Jul 8, 2026

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I tried running this test using vanilla Apache Calcite and it didn't fail; it looks like this has already been fixed in CALCITE-7276.
I think I'll wait for #13274 to be completed and then check again.
If it is fixed, then we can simply add the tests to this PR.

super.validateUpdate(call);

SqlSelect srcSelect = call.getSourceSelect();
SqlValidatorScope scope = getWhereScope(srcSelect);

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why where scope? Looks like selectItems are validated within select scope and selectItems derived from sourceExpressionList. Maybe sourceExpressionList also should be validated within select scope? (I'm not quite sure about this. Maybe there is a reason for where scope?)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems more correct to use the WHERE clause, because we need to work only with aliases of the table being updated, rather than the entire SELECT statement, which might include auxiliary aliases.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants