maria-discuss team mailing list archive

[Tom Worster <fsb@xxxxxxxxxx>]

Hi Sergei, 

On 2/3/15, 7:13 AM, "Sergei Golubchik" <serg@xxxxxxxxxxx> wrote:

>> 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.

There may be no *technical* reason why it couldn't be but I see no
*logical* reason why it would be. I can understand how tables (be they
schema, temp or select) need NULL to say "it's not here" but a dynamic
column existing and having a "value" of NULL is a non-sequitur. Writing a
NULL to a dynamic column currently deletes it and I think that makes
perfect sense. (I think we see know how the word "column" in "dynamic
columns" can be misleading.)


>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).

I see what you mean but it's not a very useful answer. Much more useful to
get the names, datatypes and structure plus all the values that aren't
non-unicode strings.

Tom