maria-discuss team mailing list archive

[Sergei Golubchik <serg@xxxxxxxxxxx>]

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.