rename types.Binary to types.LargeBinary, add types.BINARY and types.VARBINARY

[Former user]

When using, for example, a types.Binary(16) column in the Mysql dialect, a BLOB(16) is generated, instead of the native type BINARY(16).

This is a problem because: * BLOB columns cannot be used as index without additional work ("BLOB/TEXT column 'iid' used in key specification without a key length") * The BLOB storage format is less space-efficient then BINARY * Using a fixed any-length field meant for storing images etc for storing a fixed length binary string like a Hash or UUID is overkill

[Mike Bayer]

I'm assuming that you're aware of sqlalchemy.dialects.mysql.BINARY and sqlalchemy.dialects.mysql.VARBINARY (as well as all the other BLOB types mysql has). So there's no inability to use these types (they're in 0.5 too, though with names like MSBinary, MSMediumBlob etc.).

The real issue here is that types.Binary is confusing in that it is named the same as the sql type BINARY. It is not intended as a "short binary" type since most backends do not have such a type, and it is not possible to have such a type generically. It's documented as producing BLOB/BYTEA/similar only.

The MS-SQL dialect is actually producing this "switching" behavior when it receives Binary, this is also problematic.

So in addition to MySQL/MS-SQL providing a BINARY and VARBINARY type, these types will also be added to types as "SQL standard" types, so that an application can use BINARY/VARBINARY across these two supporting platforms without using a type decorator. Binary itself will be renamed to LargeBinary. LargeBinary will only produce BLOB or similar on a backend, no such "switching" behavior will be provided. The "length" field will still be accepted as a "size tuning" parameter used by backends which accept one such as MySQL.

[Mike Bayer]

fc92d14bbe3077ff94df108bf53ec77e0da83dd8

[Mike Bayer]

Removing milestone: 0.6.0 (automated comment)