Yes, sorry for my mistake there, I realised about it too late and was in the process of fixing it, but it took me quite some time to find a way to determine the actual data type returned from `case`.
In your examples, you are missing one important issue: what's the type of string literal. Check out those examples: PostgreSQL http://sqlfiddle.com/#!17/c6522/1 - string literals are of `UNKNOWN` type, that behaves like `VARCHAR` - `case when` on `CHAR` arguments returns `CHAR` type. MSSQL: http://sqlfiddle.com/#!18/50a92/1/0 (click `browser` schema button) - string literals are `VARCHAR` - `case when` return type strictly follows the standard - `CHAR(8)` Oracle: http://sqlfiddle.com/#!4/50a92/1/0 (click `browser` schema button) - string literals are `CHAR` - `case when` return type `VARCHAR` This is still hardly conclusive to motivate the change for me. I'm not sure why are you rejecting my proposal to change default string literal type to `VARCHAR`. It would fix all of our `CHAR` problems (comparisons, connector support, functions support, etc) for now and `case when` would return `VARCHAR` automatically. Even if in the future we would want to provide a configuration switch `string-literals-type: char/varchar`, such configuration option would be cleaner and much easier to understand compared to `shouldConvertRaggedUnionTypesToVarying`. [ Full content available at: https://github.com/apache/flink/pull/6519 ] This message was relayed via gitbox.apache.org for [email protected]
