[
https://issues.apache.org/jira/browse/FLINK-24413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17428198#comment-17428198
]
Marios Trivyzas commented on FLINK-24413:
-----------------------------------------
Then, what's the purpose then for supporting CHAR(<precision>) and
VARCHAR(<precision>) if they behave as STRING() without any constraints? If
it's to keep the compatibility with DBs, I would argue that when the user
defines CHAR(5) has certain expectation as well instead of using for example
TEXT (postgres' version of STRING).
* *Spark* enforces check only on the output for VARCHAR and for CHAR for
reading input and producing fixed length string (by padding if shorter)
https://spark.apache.org/docs/latest/sql-ref-datatypes.html
* *Snowflake* seems to treat all of TEXT/STRING/VARCHAR/CHAR as synonymous
regardless of precision
https://docs.snowflake.com/en/sql-reference/data-types-text.html#data-types-for-text-strings
* *Hive* seems to be closer to standard RDBMS behaviour, so for VARCHAR it
truncates strings above the precision, for CHAR it also pads to reach the
precision specified [https://data-flair.training/blogs/hive-data-types/]
> 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
>
> *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.3.4#803005)
