Hi, Tom!
On Feb 01, Tom Worster wrote:
> 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.
Right...
> 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.
Hmm. May be a dynamic column cannot be NULL now, but this is not a
conceptual limitation, there is no logical reason why it coldn't be.
So I'd rather keep JSON null for that. What I mean was that the whole
COLUMN_GET should fail and return NULL, just as any function does when
it gets invalid input:
MariaDB [test]> select uncompress("foobar"), 1/0, sqrt(-2);
+----------------------+------+----------+
| uncompress("foobar") | 1/0 | sqrt(-2) |
+----------------------+------+----------+
| NULL | NULL | NULL |
+----------------------+------+----------+
(it can also throw a warning, like uncompress does).
Regards,
Sergei
> >> What *should* COLUMN_JSON() do when a dynamic column contains
> >> BINARY values?
> >>
> >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.
_______________________________________________
Mailing list: https://launchpad.net/~maria-discuss
Post to : maria-discuss@lists.launchpad.net
Unsubscribe : https://launchpad.net/~maria-discuss
More help : https://help.launchpad.net/ListHelp
