FoundationDB/sql-layer — pull request #1110 by MMcM (2013-12-16 21:38:00+00:00)
Title: More types translator

I'm afraid there isn't a consistent theme to these changes, other than eliminating references to mcompat from the sql packages. And adding methods to the new types translator as needed to do what they were doing. The goal is to keep the higher level behavior the same, which is why no new tests are introduced.

Some references remain, such as zero date mode handling in the PG server, which is specific to instances of those specific types. This could be some kind of abstract hook, if a goal were to have a build without mcompat at all. But for now, it will just not be invoked when other bundles are in use.

The most delicate changes are to the binary encoding of values by ```ServerValueEncoder```/```Decoder```. These are tested by the recent PG binary-mode test. And I double-checked them against pg8000, which uses binary most of the time. This area is made somewhat worse by parameter support having been put into types3 pretty late. Type propagation does not work completely and does not take the intended type given by the client into account (so that fewer CASTs are present than ought to be). And the contract of ```fromObject``` is not well defined, tending to refuse an int for a long while accepting an int meant to represent a timestamp as an ordinary one. The new types translator is a start in the right direction, since it pairs raw values with JDBC types, but not complete yet. And ```ValueSources``` remains one of the places that knows about mcompat explicitly. In some cases, a query, such as ```CONCAT('today is ',?)``` when passed a binary datetime, that previously got the wrong result by exposing the internal representation, now gets an error. This wasn't an explicit goal, but falls out of where the work is cut off. More of the above is needed to get it to give the correct answer.