[
https://issues.apache.org/jira/browse/FLINK-24413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17450477#comment-17450477
]
Marios Trivyzas commented on FLINK-24413:
-----------------------------------------
It seems that currently when we cast to a *CHAR(<precision>)* we do padding for
string values with length < *precision* only for literals, but not for values
coming out of actual fields.
This is a very confusing behaviour for a user, as user's would very likely use
literals in an SQL stmt to "test" some behaviour, and would be surprised that a
*CAST('foo' AS CHAR(5))* results in *"foo "* but a *CAST(<fieldName> AS
CHAR(5))* will result in "{*}foo"{*} (no padding).
We should definitely change the behaviour to achieve consistency here, by:
# Don't apply padding also for literals
# Apply padding for normal string field values
I'd vote for option *2.*
[~twalthr] [~jark] What's your take on this?
> Casting to a CHAR() and VARCHAR() doesn't trim the string to the specified
> precision
> ------------------------------------------------------------------------------------
>
> Key: FLINK-24413
> URL: https://issues.apache.org/jira/browse/FLINK-24413
> Project: Flink
> Issue Type: Sub-task
> Components: Table SQL / API
> Reporter: Marios Trivyzas
> Priority: Major
> Labels: pull-request-available
>
> *CAST**('abcdfe' AS CHAR(3))* should trim the string to 3 chars but currently
> returns the whole string *'abcdfe'*.
>
> PostgreSQL and Oracle for example behave as such:
> postgres=# select '123456afas'::char(4);
> bpchar
> --------
> 1234
> (1 row)
> postgres=# select '123456afas'::varchar(5);
> varchar
> ---------
> 12345
> (1 row)
--
This message was sent by Atlassian Jira
(v8.20.1#820001)
