[
https://issues.apache.org/jira/browse/DRILL-5419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15998812#comment-15998812
]
ASF GitHub Bot commented on DRILL-5419:
---------------------------------------
Github user jinfengni commented on the issue:
https://github.com/apache/drill/pull/819
My understanding is Drill would hit a schema change between column with
type of varchar(5) and varchar(10). However, the length calculated in this PR
is from the query metadeta (function parameter, string literal), which will not
change across different batches. In that sense, we should not see schema change
exception, just because of varchar length.
The following code shows that varchar(5) is different from varchar(10),
also different from varchar without setting length.
```java
TypeProtos.MajorType varchar5 = TypeProtos.MajorType.newBuilder()
.setMinorType(TypeProtos.MinorType.VARCHAR)
.setMode(TypeProtos.DataMode.OPTIONAL)
.setPrecision(5)
.build();
TypeProtos.MajorType varchar10 = TypeProtos.MajorType.newBuilder()
.setMinorType(TypeProtos.MinorType.VARCHAR)
.setMode(TypeProtos.DataMode.OPTIONAL)
.setPrecision(10)
.build();
TypeProtos.MajorType varcharNoLength = TypeProtos.MajorType.newBuilder()
.setMinorType(TypeProtos.MinorType.VARCHAR)
.setMode(TypeProtos.DataMode.OPTIONAL)
.build();
System.out.println(varchar5.equals(varchar10) ? "varchar5 equals
varchr10" : "varchar5 NOT equals varchr10" );
System.out.println(varchar5.equals(varcharNoLength) ? "varchar5 equals
varchrNoLength" : "varchar5 NOT equals varchrNoLength" );
```
output:
```
varchar5 NOT equals varchr10
varchar5 NOT equals varchrNoLength
```
> Calculate return string length for literals & some string functions
> -------------------------------------------------------------------
>
> Key: DRILL-5419
> URL: https://issues.apache.org/jira/browse/DRILL-5419
> Project: Apache Drill
> Issue Type: Bug
> Affects Versions: 1.9.0
> Reporter: Arina Ielchiieva
> Assignee: Arina Ielchiieva
> Attachments: version_with_cast.JPG
>
>
> Though Drill is schema-less and cannot determine in advance what the length
> of the column should be but if query has an explicit type/length specified,
> Drill should return correct column length.
> For example, JDBC / ODBC Driver is ALWAYS returning 64K as the length of a
> varchar or char even if casts are applied.
> Changes:
> *LITERALS*
> String literals length is the same as actual literal length.
> Example: for 'aaa' return length is 3.
> *CAST*
> Return length is the one indicated in cast expression. This also applies when
> user has created view where each string columns was casted to varchar with
> some specific length.
> This length will be returned to the user without need to apply cast one more
> time. Below mentioned functions can take leverage of underlying varchar
> length and calculate return length.
> *LOWER, UPPER, INITCAP, REVERSE, FIRST_VALUE, LAST_VALUE*
> Return length is underlying column length, i.e. if column is known, the same
> length will be returned.
> Example:
> lower(cast(col as varchar(30))) will return 30.
> lower(col) will return max varchar length, since we don't know actual column
> length.
> *LAG, LEAD*
> Return length is underlying column length but column type will be nullable.
> *LPAD, RPAD*
> Pads the string to the length specified. Return length is this specified
> length.
> *CONCAT, CONCAT OPERATOR (||)*
> Return length is sum of underlying columns length. If length is greater then
> varchar max length, varchar max length is returned.
> *IF EXPRESSIONS (CASE STATEMENT, COALESCE), UNION OPERATOR*
> When combining string columns with different length, return length is max
> from source columns.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
