[
https://issues.apache.org/jira/browse/CALCITE-7637?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18093778#comment-18093778
]
Kirill Tkalenko commented on CALCITE-7637:
------------------------------------------
[~mbudiu] [~julianhyde]
It was my mistake; this issue belongs in the
[Ignite|https://issues.apache.org/jira/projects/IGNITE] project, and I didn't
notice that the first time around. So, I closed that ticket and created a new
one in the correct project.
Just an observation: when overriding the binary "-" operator for the TIMESTAMP
- NUMERIC, the types aren't resolved correctly after validation.
However, this is currently observed in the Ignite project, which is still using
Calcite version 1.40. I hope to upgrade to 1.42 soon and verify the behavior
there.
I think I'll try testing it on the latest calcite "main" version.
> Fix DML for overloaded binary operators in Calcite engine
> ---------------------------------------------------------
>
> Key: CALCITE-7637
> URL: https://issues.apache.org/jira/browse/CALCITE-7637
> Project: Calcite
> Issue Type: Bug
> Reporter: Kirill Tkalenko
> Assignee: Kirill Tkalenko
> Priority: Major
> Labels: ignite-2
>
> I discovered that when overloading a binary operator in the Calcite engine,
> it works for SELECT statements but not for UPDATE statements.
> For example, when overloading the binary operator "-" for the operation
> TIMESTAMP -NIMERIC, SELECT queries work as expected, but UPDATE queries do
> not; this needs to be fixed.
> {code:java}
>
> sql("create table person(id int primary key, val_ts timestamp)");
> sql("insert into person values (?, ?)", 1, Timestamp.valueOf("2024-01-01
> 00:00:00"));
> // Check SELECT - works.
> assertQuery("SELECT val_ts - 1 FROM person")
> .returns(Timestamp.valueOf("2023-12-31 00:00:00"))
> .check();
> // Check UPDATE - fails.
> assertQuery("UPDATE person SET val_ts = val_ts - 1 WHERE id = ?")
> .withParams(1)
> .returns(1L)
> .check();
> {code}
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
