Description:
MySQL is missing an argument in its hash functions to specify binary vs hex output. This is odd, as inside the database, most hashes would be stored in binary. If you have a field "value_md5 binary(16)" and the client doesn't handle the processing on its side, writes end up looking like "insert into table set value_md5=unhex(md5('value'));"
The overhead of that function is low, but it's adding extra steps for the server to generate the hash, hex-encode it, then decode again to binary - and that could be very simply avoided.
Seems like most database-internal uses of a hash function want binary rather than hex, so this would cover the majority of use cases.
How to repeat:
call a hash function, see http://dev.mysql.com/doc/refman/5.6/en/encryption-functions.html
Suggested fix:
add an optional second parameter to hash functions that could be 0/1 (or whatever) for binary output. default to hex-encoded for backwards compatibility.
Description: MySQL is missing an argument in its hash functions to specify binary vs hex output. This is odd, as inside the database, most hashes would be stored in binary. If you have a field "value_md5 binary(16)" and the client doesn't handle the processing on its side, writes end up looking like "insert into table set value_md5=unhex(md5('value'));" The overhead of that function is low, but it's adding extra steps for the server to generate the hash, hex-encode it, then decode again to binary - and that could be very simply avoided. Seems like most database-internal uses of a hash function want binary rather than hex, so this would cover the majority of use cases. How to repeat: call a hash function, see http://dev.mysql.com/doc/refman/5.6/en/encryption-functions.html Suggested fix: add an optional second parameter to hash functions that could be 0/1 (or whatever) for binary output. default to hex-encoded for backwards compatibility.