FoundationDB/sql-layer — pull request #1101 by MMcM (2013-12-12 23:55:34+00:00)
Title: Make the type translator depend on the context

Replace TypesTranslation, with a static method, by an abstract class, whose instance is available in ```SchemaRulesContext``` (etc.)

I'm not sure whether this is easier to understand as separate commits, since some of the changes in earlier ones are immediately redone by later ones. But, they are,
* 2077af65449ae5db2290b9407f96249a6e37e03c make the ```TInstance``` to ```BaseExpression``` come from the constructor arguments rather than the constructor body. So, all the places that instantiate (mostly ```ASTStatementLoader```) need to call the translator.
* 8ed62143f135e8c697f8db2de0b5f6f91ee1ba0c add ```TypesTranslator``` which translates from a SQL type to a types3 type. The common currency of the generic bits is mostly (that is, except for some weird MySQL cases) JDBC types, which seems as good as anything else.
* 3c4f0d88263e12924f808112a0594c00692c6248 Make an instance available to the rules context via the server session. Ultimately, you get the mcompat singleton, but only one place knows that.
* b7dbd886aedc115e5ef61dcfd366d3ae3c620cc2 Replace uses.
* dfa4c154226326f072c1aa5cf934fbef0840cd2d Delete old translator which is now unused.

Additionally, because of the new structure, the types translator will be available for other uses where the caller just wants the "standard" VARCHAR or INT type, whatever that is. Particularly when it has a Java string or integer to shove in.

f325f5c1620984b4391f6d4456ca202752ac7060 is to restore compatibility for the time being with the old translator. The SQL CHAR type gets translated into MCOMPAT_ VARCHAR, even though there is a CHAR type. The issue is that otherwise ```col LIKE 'str'``` adds a CAST to the column to VARCHAR(255) because that's what comes out of the overload picker in the VARCHAR+CHAR case. That needs to be fixed, but shouldn't hold up this thread of work.