[
https://issues.apache.org/jira/browse/FLINK-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16594669#comment-16594669
]
ASF GitHub Bot commented on FLINK-9559:
---------------------------------------
pnowojski edited a comment on issue #6519: [FLINK-9559] [table] The type of a
union of CHAR columns of different lengths should be VARCHAR
URL: https://github.com/apache/flink/pull/6519#issuecomment-416196736
@hequn8128, as I wrote before, we can not support hundreds of switches
modifying semantic of SQL, especially not in so minor ways. This PR also do not
fix your original issue - broken `CHAR(x)` support in Flink.
Output column type of `CHAR(x)` should be properly handled by each
connector. For example if Flink is processing some `CHAR(X)` column which is
then being written to some sink/connector, it's this Sink's responsibility to
correctly handle padding - whether that means trimming it or not depends on the
underlying column's type. Again, changing type of `case when` only partially
hides the problem.
> I think we should not add trailing spaces in result of case when, just
like most DBMSs do.
Further more, please correct me if I'm wrong, but this sentence seems not
quite correct:
MySQL http://sqlfiddle.com/#!9/ce6d86/1
1. string literals seems to be of `VARCHAR(x)` type.
2. `CONCAT` on `CHAR(x)` is broken
3. indeed `case when` returns `VARCHAR(x)`
Oracle http://sqlfiddle.com/#!4/ce6d86/1
1. string literals seems to be `VARCHAR`
2. type of `case when` calculated dynamically, depending which branch was
selected, but looks like `CHAR(x)`
PostgreSQL
http://sqlfiddle.com/#!17/ce6d8/1
http://sqlfiddle.com/#!17/c6522/1/0
1. again, string literals are of `UNKNOWN` type
2. `case when` return type is `CHARACTER`.
MSSQL http://sqlfiddle.com/#!18/ce6d8/2
1. again, string literals seems to be `VARCHAR`
2. oO... I'm not even attempting to interpret those results... probably
`concat` on `VARCHAR` with trailing spaces is seriously broken
Btw, if you look at those results, you should understand why I'm objecting
into providing a configuration switch (or more like a hundred of them) in order
to follow what "other DBMSs do". This is simply impossible...
Also as I wrote previously. The proper fix for the problem would be to
either fix `CHAR(x)` support or to change string literals' type to `VARCHAR(x)`.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
> The type of a union of CHAR columns of different lengths should be VARCHAR
> --------------------------------------------------------------------------
>
> Key: FLINK-9559
> URL: https://issues.apache.org/jira/browse/FLINK-9559
> Project: Flink
> Issue Type: Bug
> Components: Table API & SQL
> Reporter: Hequn Cheng
> Assignee: Hequn Cheng
> Priority: Major
> Labels: pull-request-available
>
> Currently, If the case-when expression has two branches which return string
> literal, redundant white spaces will be appended to the short string literal.
> For example, for the sql: case 1 when 1 then 'a' when 2 then 'bcd' end, the
> return value will be 'a ' of CHAR(3) instead of 'a'.
> Although, this follows the behavior in strict SQL standard mode(SQL:2003). We
> should get the pragmatic return type in a real scenario without blank-padded.
> Happily, this problem has been fixed by
> [CALCITE-2321|https://issues.apache.org/jira/browse/CALCITE-2321], we can
> upgrade calcite to the next release(1.17.0) and override
> {{RelDataTypeSystem}} in flink to configure the return type, i.e., making
> {{shouldConvertRaggedUnionTypesToVarying()}} return true.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
