Re: DBD::mysql path forward

On Tuesday 26 September 2017 14:20:33 Night Light wrote:
> I noticed that it was mentioned in DBD::mysql # 117 that DBD::mysql does
> know that a column in a returned resultset is a BLOB.

For returned values via MySQL protocol, there are two different and
independent things: SQL type and encoding. Which means that *returned*
data of type BLOB have encoding, and it can be encoded in UTF-8.

Moreover, MySQL server is known to send TEXT columns as type BLOB with
indication of the UTF-8 encoding.

> One should also consider the performance penalty of encoding/decoding
> BLOB's as they can be big.

Patches which were part of 4.042 release called UTF-8 decoding routine
for retrieved data only if MySQL server told that data are UTF-8
encoded. And independently of the type. Of course there is also "binary"
encoding in MySQL protocol and server can use it.

UTF-8 decoding has linear time complexity (in case of valid input data).
For large data it could be performance penalty, but returning *wrong*
and *invalid* data is worse as returning data slower.

Also note that MySQL SQL language has a functions for conversion, so it
is up to programmer to write SQL statement in correct way. There is a
MySQL SQL function to convert string into binary...

Also note that for non-served-side-prepared-statements the only
communication protocol between client and server is text based protocol.
And converting binary data to text on both side (client C library and
server library) would have probably bigger penalty as some UTF-8 decoder
in DBD driver.