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.
