Clarify use of absent-valued attribute names in a tuple constructor

[johnedquinn]

Description

The PartiQL Maintainers had a discussion regarding the semantics of tuple construction when an attribute name expression evaluates to NULL/MISSING.

Summary & Outcome

Attribute names that evaluate to the null value are not allowed. In permissive mode, they'll be stripped from the tuple.

PartiQL Specification

Treatment of mistyped attribute names It is possible that an expression ai that computes an attribute name results into a non-string, i.e., a value that is not a legitimate attribute name. In such cases, under the permissive mode the attribute-value pair will be dismissed. Under the type checking mode the query will fail.

Discussion Snippets

From @alancai98:

My read of the spec (i.e. absent values are non-strings) would have 6/7 follow the same behavior

> 6. { 'a': 1, null: 2 }       == { 'a': 1 }              
> 7. { 'a': 1, missing: 2 }    == { 'a': 1 }

If we preserve null as the key name for null: 2, it feels somewhat nonsensical since we can't do a path of { 'a': 1, null: 2 }.null to retrieve the associated value, 2.

From @johnedquinn:

I'm aligned with Alan's take, since it's the most sane. But wanted to note two sentences from SQL:1999 as for why the spec should be made more clear:

> Character string types, bit string types, and binary string types are collectively referred to as string types and values of string types are referred to as strings.
> -- Part 2, Section 4.1

> Every data type includes a special value, called the null value, sometimes denoted by the keyword NULL.
> -- Part 1, Section 4.2

Since values of the string type are referred to as strings and the null value is included within the string type, the null value may be referred to as a string. AKA, it is not a non-string. Hence, where my question came from. The PartiQL spec in my opinion should be updated to say:

> Attribute names must evaluate to non-null strings.
>
> It is possible that an expression ai that computes an attribute name results in a value that is not a legitimate attribute name. In such cases, under the permissive mode the attribute-value pair will be dismissed. Under the type checking mode the query will fail.

From @am357:

> …the null value may be referred to as a string. AKA, it is not a non-string.

I guess this is where I am misaligned. The null absent value only denotes absence of a value in my view, hence we cannot interpret it as a string value. As you pointed out, based on SQL specification, it is still within the domain of string type. If I would want to revise the spec. I would change it as follows:

> It is possible that an expression ai that computes an attribute name results into a non-string value.
>
> This is b/c I see the non-null or NOT NULL being the property of the column (attribute) rather than representing an actual value; the literal null represents an absence of a value. Viewing with this lens, I see the non-null string being an oxymoron.

Overall perhaps we are just quibbling here and I honestly have been using the same phrases myself before, so, don’t know :shrug:

Action Item

Update the specification to make clear what it means by non-strings. Do we adopt SQL's wording of strings?

[am357]

Update the specification to make clear what it means by non-strings. Do we adopt SQL's wording of strings? Maybe we can clarify which wording. If it is Part 2, Section 4.1 of SQL:1999 I would not adopt that since it is discussing about the types rather than values.