Dmitry, > > To sum it up, standard dictates that literals are CHARs, aggregated > > values has length of longest one and because CHARs are padded with > > spaces to declared length, we have such stupid output in CASE. Sure, > > it could be easily "fixed" with CAST or TRIM, but it's extremely > > annoying to do so. And if there is any real world case when CHAR is > > the right type for literals and VARCHAR the wrong one, I can't see it > > and would be glad to be enlightened by someone else. > > First of all, let's distinguish between two things: (1) how string literals > are > described and (2) how CASE evaluates the resulting datatype. Changing any > of them may lead to the desired result.
The issue is not the intermediate datatype but the final datatype. In Pavel's use case "color" is a VarChar as such any value/string/variable which is assigned to it should be cast as a VarChar, regardless of the intermediate datatype. The current outcome is wrong! Sean P.S. The fact that a fix for this could introduce compatibility issues is not a something we should care about when fixing invalid/wrong functionality. Compatibility issues are items which developers need to resolve for themselves, nothing is forcing a developer to adopt v3. ------------------------------------------------------------------------------ Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
