Need to add NULL as a literal value.
In most programming languages, including the ones you mentioned, an attribute with ‘no value’ has the value null. That is not a string literal, it is a concept. Such a concept exists in most serialization formats and languages as well, so it can be serialized to a string.
Since sometimes a single value is not present for rows as the result of a query, it must be possible to indicate that there is no data present in that single value corresponding to a part in the select clause of the query. if the result set is a two-dimensional array, so an array of arrays of values, there must be a way to indicate that in that specific place in that array, no data has been found. Otherwise it is not possible to determine to which value corresponds to which part of the select clause. That means it needs to be possible for the result to contain null values.
So I would propose to leave that sentence as is, and to keep null values, including in any json serialization. That will not be a string with the value ‘NULL’, but it will be the representation of a null value in that particular serialization. In json, it is represented by null, as in the specification at https://www.json.org/json-en.html . And as in the following example containing a number, a string, a null value, a boolean and an object, in json:
Which is not a string literal, but certainly not ‘for comparison expressions only’
An alternative could be to not use arrays, but to map each value in a result row to some kind of key, such as the alias of that part of the select query, or the selected path, expression or literal in full, or a numbered index of that specific part of the select query, and omitting that key altogether if it is not present in data. Since that is explicitly not part of the AQL specification, the null-value solution seems good to me.
No , I did not ment the string 'NULL' , neither "NULL”, but the NULL itself.
In meanwhile I see also responded - and I agree with his (json) feedback and example: [1, "string value", null, true]
My reason to change the original text was that the specs was not considering the case of no-data, i.e. NULL, as that is not an object, neither a primitive or build-in / constructed type:
…where Any is understood as the superclass of all object types, including primitive and constructed types.
I don’t work with JSON much; do standard serialisers e.g. Java → JSON generate the string ‘null’ in the output? And deserialisers understand it in the other direction?
In materialised structures, i.e. actual in-memory arrays of reference objects, there’s no ambiguity: null values are slots/cells with the null value of the reference type (almost always some kind of null pointer). For primitive types it is a bit more complex, since there is no idea of ‘null’ for types like ‘int’, ‘float’ etc - they are in-place values.
I guess we all know how our favourite programming languages function in this aspect, but we need to be careful about what we are saying with respect to serial structures i.e. JSON, XML etc.
Some extra info: NULL is present and documented in most of the SQL languages I checked. And it goes even further, as you are not ‘allowed’ (in SQL) to compare or use other operators with NULL, other than the ‘IS’ operator. See links:
It is certainly very useful for the ‘flattened out’ scalar values