flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] pnowojski edited a comment on issue #6519: [FLINK-9559] [table] The type of a union of CHAR columns of different lengths should be VARCHAR
Date Tue, 28 Aug 2018 07:56:44 GMT
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:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message