[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Magnus Mogren updated CALCITE-4903:
-----------------------------------
Description:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug because:
# It affects all Calcite adapters. In my example above no remote call is ever
done.
# The values in the values-clause is distorted by the driver. It is not just
faulty metadata returned by the call to ResultSet.getMetaData() but the actual
returned data itself that are corrupted.
was:
When executing a values clause, the avatica driver returns the wrong values.
It seems it checks what value is longest and then pads all other values in the
values clause to the same length.
{*}SQL{*}:
{code:java}
select * from (values ('a'),('abcd')){code}
{*}Expected values to be returned{*}:
{{'a'}}
{{'abcd'}}
{*}Actual values returned{*}:
{{'a '}}
{{'abcd'}}
It seems that for some reason the driver thinks the columns for the
values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
the ResultSet returned when executing the SQL statement. Indeed it returns 1
(java.sql.Types.CHAR)
In my optinion this is a high priority bug since it affects any and all calcite
adapters. In my example above no remote call is ever done.
> Avatica pads values returned from values-clause to same length
> --------------------------------------------------------------
>
> Key: CALCITE-4903
> URL: https://issues.apache.org/jira/browse/CALCITE-4903
> Project: Calcite
> Issue Type: Bug
> Components: avatica, jdbc-driver
> Affects Versions: avatica-1.19.0
> Reporter: Magnus Mogren
> Priority: Major
>
> When executing a values clause, the avatica driver returns the wrong values.
> It seems it checks what value is longest and then pads all other values in
> the values clause to the same length.
> {*}SQL{*}:
> {code:java}
> select * from (values ('a'),('abcd')){code}
> {*}Expected values to be returned{*}:
> {{'a'}}
> {{'abcd'}}
>
> {*}Actual values returned{*}:
> {{'a '}}
> {{'abcd'}}
> It seems that for some reason the driver thinks the columns for the
> values-clause should be treated as fixed length CHAR(4) instead of VARCHAR.
> This is also verified by calling ResultSet.getMetaData().getColumnType(1) for
> the ResultSet returned when executing the SQL statement. Indeed it returns 1
> (java.sql.Types.CHAR)
> In my optinion this is a high priority bug because:
> # It affects all Calcite adapters. In my example above no remote call is
> ever done.
> # The values in the values-clause is distorted by the driver. It is not just
> faulty metadata returned by the call to ResultSet.getMetaData() but the
> actual returned data itself that are corrupted.
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
