Addresses some conformance edge cases

[johnedquinn]

Description

• This PR addresses some small bugs that are fairly self explanatory.
• The only meaningful change has to do with Section 6.1.1.1 Tuple Constructors (Mistyping Cases):

In the permissive mode, the query:

SELECT VALUE {v.a: v.b}
FROM [{'a':'legit', 'b':1}, {'a':400, 'b':2}] AS v

results into

<<{'legit':1}, {}>>

Notice that the attempt to create an attribute named 400 failed, thus leading to a tuple with no attributes.

Other Information

• Updated Unreleased Section in CHANGELOG: NO
• Any backward-incompatible changes? NO
• Any new external dependencies? NO
• Do your changes comply with the Contributing Guidelines
  and Code Style Guidelines? YES

License Information

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

[alancai98]

one followup comment for a struct constructor edge case. otherwise looks good

[alancai98]

Why is null returned for the overall struct constructor expression if one key is null? For the following query,

SELECT VALUE {v.a: v.b} FROM [{'a':'legit', 'b':1}, {'a':null, 'b':2}] AS v

<< { legit: 1 }, null >> will currently be the output.

My read of the "Treatment of mistyped attribute names" section of the PartiQL spec is that null struct key values (alike non-strings and missing values) would just omit that struct field from the struct in permissive mode. Following my read, the above query would result in << { 'legit': 1 }, {} >>.

[johnedquinn]

Ok, nice! From our offline discussion, I've created an issue with the team's consensus on behavior as well as the need for potential clarification in the PartiQL Spec: partiql/partiql-lang#88

I've just updated this PR accordingly. I also needed to rebase off of the type-renaming PR. The last two commits represent what has been updated.

[alancai98]

one followup comment for a struct constructor edge case. otherwise looks good