There's a lot to unpack here, but the tl;dr is to refer to the charset ultimately to determine if the data is binary, or non-binary which is always UTF-8.
This fixes behavior around CHAR/TEXT fields with a binary collation, being surfaces as BINARY/BLOB types by MySQL.
For all intents and purposes, BLOB/BINARY/CHAR/TEXT are all effectively identical and interchangeable, the only differentiator is their charset. Either they are a binary charset, or they are encoded as UTF-8.
This behavior seems to differ slightly from vanilla MySQL and is specific to potentially a bug in Vitess, but this default is much safer for future proofing if we fix things there.
There's a lot to unpack here, but the tl;dr is to refer to the charset ultimately to determine if the data is binary, or non-binary which is always UTF-8.
This fixes behavior around CHAR/TEXT fields with a binary collation, being surfaces as BINARY/BLOB types by MySQL.
For all intents and purposes, BLOB/BINARY/CHAR/TEXT are all effectively identical and interchangeable, the only differentiator is their charset. Either they are a binary charset, or they are encoded as UTF-8.
This behavior seems to differ slightly from vanilla MySQL and is specific to potentially a bug in Vitess, but this default is much safer for future proofing if we fix things there.
Fixes #169 #171