[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17449293#comment-17449293
]
Julian Hyde commented on CALCITE-4903:
--------------------------------------
[~nobigo], I agree. It's not an Avatica problem - Avatica is abiding by
Calcite's decision that the types are {{{}CHAR(4){}}}. It can be solved by
configuring Calcite differently.
> 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: Critical
>
> 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)
> IMHO 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)
