Hi Sergei,
On 2/3/15, 7:13 AM, "Sergei Golubchik" <s...@mariadb.org> 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
_______________________________________________
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
