Julian Hyde, what is your take? I think it is sufficient to add an additional check on the type to cast to (it should be CHAR) before trimming the value?

I quickly read the spec and it appears that CHAR is not to be trimmed when converting to VARCHAR. From 6.13 <cast specification>:

c) If SD is fixed-length character string, variable-length character string, or large object character string, then
Case:
i) If the length in characters of SV is less than or equal to MLTD, then TV is SV.
ii) If the length in characters of SV is larger than MLTD, then TV is the first MLTD characters of SV. If any of the remaining characters of SV are non-<space> characters, then a completion condition is raised: warning — string data, right truncation.

So it looks if current behavior is incorrect. However, I do recall a bug with

insert into t2 select ' ' as twoSpace from t union all select ' ' as threeSpace from t

where the target column in t2 is a varchar(4). We should make sure not to break that again. The twoSpace value must not be padded to three spaces when it is implicitly converted from CHAR(2) to CHAR(3). IIRC it should be converted directly to a varchar(4).

Julian Hyde, I have created a pull request in https://github.com/apache/calcite/pull/221 . Would you be able to review it? Thanks

I will try to get to it – swamped for the next day or two.

No problem Julian. Thanks

Jesus Camacho Rodriguez, I reviewed and added some tests. I concluded that your changes are OK, but we should be padding when converting to CHAR. You can see the tests and fixes in my branch https://github.com/julianhyde/calcite/tree/1199-padding. Can you review, and if it looks OK rebase, squash my commit into yours and push.

Julian Hyde, thanks a lot. I did not have time to check this yet; I will review, squash and commit by tomorrow.

Fixed in http://git-wip-us.apache.org/repos/asf/calcite/commit/ebb68da.

Thanks Julian Hyde

Resolved in release 1.8.0 (2016-06-13).