[
https://issues.apache.org/jira/browse/CALCITE-4903?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450592#comment-17450592
]
Julian Hyde edited comment on CALCITE-4903 at 11/29/21, 5:00 PM:
-----------------------------------------------------------------
[~mamo], That is intended behavior of the "ragged" flag. If the types are all
the same -- trivially so, if there is only one element in the VALUES -- then
the types remain CHAR.
If you don't like that behavior, chime in on CALCITE-4590 or one of the myriad
other issues related to CHAR.
was (Author: julianhyde):
[~mamo], That is intended behavior of the "ragged" flag. If the types are all
the same -- trivially so, if there is only one element in the VALUES -- then
the types remain CHAR.
> 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)
