[
https://issues.apache.org/jira/browse/IGNITE-19353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-19353:
--------------------------------------
Description:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem with character types:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
Problem with numeric types:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS DECIMAL(2))").withParams(new
BigDecimal("123")).check();
}
{code}
The code returns original value where Postgres/Oracle/SQL Server return
conversion error.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
was:
Current implementation of expression execution runtime incorrectly translates
types of dynamic parameters because (a) it losses type informations of dynamic
parameters (see https://issues.apache.org/jira/browse/IGNITE-18831), (b) it
goes against the rules of calcite's enumerables/link4j (on which the code is
based), which expect dynamic parameters to be converted into their java values
according to their inferred types.
The following code illustrates the problem:
{code:java}
@Test
public void test() {
assertQuery("SELECT CAST(? AS
VARCHAR(2))").withParams("abcd").returns("ab").check();
}
{code}
The code returns `abcd` when `ab` is expected.
*Solution*: convert values of dynamic parameters to java values according to
type information inferred at the validation stage and pass converted values to
expression execution runtime.
> Sql. Incorrect type conversion for dynamic parameters - CAST operation
> ignores type precision.
> ----------------------------------------------------------------------------------------------
>
> Key: IGNITE-19353
> URL: https://issues.apache.org/jira/browse/IGNITE-19353
> Project: Ignite
> Issue Type: Bug
> Components: sql
> Reporter: Maksim Zhuravkov
> Priority: Major
> Labels: ignite-3
> Fix For: 3.0.0-beta2
>
>
> Current implementation of expression execution runtime incorrectly translates
> types of dynamic parameters because (a) it losses type informations of
> dynamic parameters (see https://issues.apache.org/jira/browse/IGNITE-18831),
> (b) it goes against the rules of calcite's enumerables/link4j (on which the
> code is based), which expect dynamic parameters to be converted into their
> java values according to their inferred types.
> The following code illustrates the problem with character types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS
> VARCHAR(2))").withParams("abcd").returns("ab").check();
> }
> {code}
> The code returns `abcd` when `ab` is expected.
> Problem with numeric types:
> {code:java}
> @Test
> public void test() {
> assertQuery("SELECT CAST(? AS DECIMAL(2))").withParams(new
> BigDecimal("123")).check();
> }
> {code}
> The code returns original value where Postgres/Oracle/SQL Server return
> conversion error.
> *Solution*: convert values of dynamic parameters to java values according to
> type information inferred at the validation stage and pass converted values
> to expression execution runtime.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
