Hi Sergei, base64 makes sense only if I store a base64 encoded value, which is what my ORM extension does (prefixed with 'data:application/octet-stream;base64,') for non-utf8 strings. So I say leave that to me. A dynamic column cannot be NULL, so using a JSON null (a different kind of null) to express "dynamic column exists but cannot be represented as requested" should work. The ORM would then have the names and positions in the structure of all the BINARY dynamic columns. With that it can send a SELECT with one or more COLUMN_GET(dyncol_blob, "name" AS BINARY) expressions. I could live with that. Tom On 2/1/15, 3:45 PM, "Sergei Golubchik" <serg@mariadb.org> wrote:
Hi, Tom!
On Jan 31, Tom Worster wrote:
I think we're getting lost in the detail. Beyond dispute are two facts:
1. BINARY is a valid datatype in dynamic columns. 2. JSON cannot represent binary data.
It follows that:
COLUMN_JSON() cannot (correctly) represent all dynamic column values.
So I ask the question is:
What *should* COLUMN_JSON() do when a dynamic column contains BINARY values?
When I file a bug report, I like to give an expected result. I don't know what it is in this case. Every other decent JSON encoder errors on such input. Is that what Maria should do?
I suppose MariaDB could either return a NULL (meaning "failed", "invalid input", "not possible to convert to JSON") or, may be, base64 this binary data in the output.
But base64 looks like an arbitrary choice, and it, technically, returns something that is *not* the original binary data.
Regards, Sergei