I'm slightly against having both Float and Double – I'd like to discourage premature optimization and using 4 bytes for floating point instead of 8 is almost always the wrong space:accuracy tradeoff today.
I guess I added Float and Double together because they were so similar it seemed silly not to. It is also a JDBC type and seemed easy enough to provide and make implementing the next stages of JDBC easier.
Selfishly, my implementations use a lot of small float numbers like: "1.2" or "66.667" so a row might have 50 columns of such data and 5-50 million rows. So a selfish trend on my part is to provide the smallest representation on bytes stored/in-memory.
Similarly not sure there is a raison d'être for ByteType.
My reasoning was more about a guaranteed length that was short. We plan to put ENUMs into them in prepared statements. Again, selfishly, if we have a lot of Float usage we really have a lot of numbers between 1-10 to store! So all these volumes above are just more exaggerated in our need to store lots of short numbers in an optimal width. But I do understand the variable integer IntegerType could be used.
This looks wrong:
Yep... Cut-n-paste in a hurry... will get you every time! I'll fix with v3 patch. (starting to see a trend)
Yes. I'll look into the error of my "whitespace" ways.
I will try to conjure some tests that dovetail into the existing testing framework.
A separate ticket would probably be good for ANTLR work. I'll give it a shot but am about 30 years rusty on parsing grammars. But I'll gladly give it a try.