[
https://issues.apache.org/jira/browse/IGNITE-25716?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pavel Pereslegin updated IGNITE-25716:
--------------------------------------
Description:
The following test fails
{code:java}
LocalTime time = LocalTime.parse("00:00:00.1");
assertQuery("SELECT ?::TIME") // SELECT ?::TIME(0) produces the same result
.withParam(time)
.returns(time.withNano(0))
.check();
// Expected: 00:00 <class java.time.LocalTime>
// Actual: 00:00:00.100 <class java.time.LocalTime>
{code}
The plan is
{noformat}
Project(EXPR$0=[CAST(?0):TIME(0)]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0, network=0.0], id = 28
Values(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 24
{noformat}
The type of dynamic parameter is determined as TIME(0), so Calcite doesn't
implement excessive cast (TIME::TIME) for this case.
A possible solution is to normalize the value of the dynamic parameter to a
determined type on initialization, so that when it is retrieved from the
execution context, it already has the expected precision.
p.s. Check how DECIMAL works
was:
The following test fails
{code:java}
LocalTime time = LocalTime.parse("00:00:00.1");
assertQuery("SELECT ?::TIME") // SELECT ?::TIME(0) produces the same result
.withParam(time)
.returns(time.withNano(0))
.check();
// Expected: 00:00 <class java.time.LocalTime>
// Actual: 00:00:00.100 <class java.time.LocalTime>
{code}
The plan is
{noformat}
Project(EXPR$0=[CAST(?0):TIME(0)]): rowcount = 1.0, cumulative cost =
IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0, network=0.0], id = 28
Values(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = IgniteCost
[rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 24
{noformat}
The type of dynamic parameter is determined as TIME(0), so Calcite doesn't
implement excessive cast (TIME::TIME) for this case.
A possible solution is to normalize the value of the dynamic parameter to a
determined type on initialization, so that when it is retrieved from the
execution context, it already has the expected precision.
> Sql. Normalize dynamic parameter value according to the determined type
> -----------------------------------------------------------------------
>
> Key: IGNITE-25716
> URL: https://issues.apache.org/jira/browse/IGNITE-25716
> Project: Ignite
> Issue Type: Bug
> Components: sql, sql ai3
> Reporter: Pavel Pereslegin
> Priority: Major
> Labels: ignite-3
>
> The following test fails
> {code:java}
> LocalTime time = LocalTime.parse("00:00:00.1");
> assertQuery("SELECT ?::TIME") // SELECT ?::TIME(0) produces the same
> result
> .withParam(time)
> .returns(time.withNano(0))
> .check();
> // Expected: 00:00 <class java.time.LocalTime>
> // Actual: 00:00:00.100 <class java.time.LocalTime>
> {code}
> The plan is
> {noformat}
> Project(EXPR$0=[CAST(?0):TIME(0)]): rowcount = 1.0, cumulative cost =
> IgniteCost [rowCount=2.0, cpu=2.0, memory=0.0, io=0.0, network=0.0], id = 28
> Values(tuples=[[{ 0 }]]): rowcount = 1.0, cumulative cost = IgniteCost
> [rowCount=1.0, cpu=1.0, memory=0.0, io=0.0, network=0.0], id = 24
> {noformat}
> The type of dynamic parameter is determined as TIME(0), so Calcite doesn't
> implement excessive cast (TIME::TIME) for this case.
> A possible solution is to normalize the value of the dynamic parameter to a
> determined type on initialization, so that when it is retrieved from the
> execution context, it already has the expected precision.
> p.s. Check how DECIMAL works
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
