FoundationDB/sql-layer — pull request #1305 by tjoneslo (2014-05-27 15:10:51+00:00)
Title: Typesresolver cast varchar 255

This addresses a subtle problem with input parameter to functions and overload processing in the types system.

Every function's input parameters are specified in general types (e.g. VARCHAR, CHAR, DECIMAL, etc). When the `TypesResolver` detects that the parameter's type does not match function's input parameters (e.g. VARCHAR vs CHAR), it generates a Cast operation to, when the statement is executed, put the value into the correct and expected type.

Generating a Cast operation has two parts. The first part takes the input type (TInstance) and using the OverloadResolver, overloads the specific input type to a preferred type. This is where the code change below occurs. The second part of the generation creates the function call to CAST with the correct parameters.

In the specific case noted in the [Trello card](https://trello.com/c/vlsnRViI), the input TInstance is `CHAR(5) COLLATION us_en_ci`. The Like function wants varchar parameter. Therefore the `TypesResolver` generates a CAST operation. In the first part of the generation, the OverloadResolver takes the input TInstance CHAR and overloaded it to the preferred VARCHAR type. Previous to this fix the system would create a `VARCHAR(255) UTF8 COLLATION UTF8` TInstance for the overload. This does not work correctly with LIKE because the collation attached to the input TInstance determines which of the two implementations of LIKE (case sensitive or case insensitive) to select.

The fix is pretty simple. When OverloadResolver wants to generate an overloaded VARCHAR TInstance, it should include the source size, character set, and collation. This only affects the first part of generating a cast, and only when starting type is VARCHAR-like.