Fixes several path tests according to the PartiQL Specification

[johnedquinn]

Description

• Fixes several path tests according to the PartiQL Specification

Note: Please click "Hide Whitespace" on the Files Changed tab. The file was formatted oddly, so I allowed my IDE to auto-format.

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

[yliuuuu]

I tagged duplicated comments "Same as above" to prevent losing track of the test case.

[yliuuuu]

This is really weird...

Build up on the previous test cases:

If MISSING.a is MISSING failed evalMode: EvalModeError, why should NULL.a succeed?

I understand you can coerce NULL to any type, but it does seem weird to me ....

[johnedquinn]

This PR doesn't change anything here -- it's a formatting diff.

Though, to answer with my own opinion, all SQL binary operations return null when one of the operands is the null value. AKA NULL + 1 = NULL, 1 - NULL = NULL... and, IMO, NULL.a = NULL. MISSING is a type error, and upon passing it to (almost) all functions, it results in a type error.

Though, this PR isn't adjusting these tests. It's formatting.

[yliuuuu]

Nonblocking: but we can think of path navigation as a function that is not nullCall?

[yliuuuu]

Could you please elaborate on why this failed?

SELECT VALUE v1
FROM s as v1

[johnedquinn]

From PartiQL Specification:

The expression e[∗] reduces to (i.e., is equivalent to):
SELECT VALUE v FROM e AS v

And,

In the following cases the expression in the FROM clause item has the wrong type. Under the type checking option, all of these cases raise an error and the query fails. Under the permissive option, the cases proceed as follows
-- Section 5.1.1: Mistyping Cases

Therefore,

<scalar>[*] = SELECT VALUE v FROM <scalar> AS v --> FROM clause item has the wrong type.

[yliuuuu]

Could you please elaborate on why this failed?

SELECT VALUE v1 
FROM UNPIVOT s as v1

[yliuuuu]

Spec section 5.1.1 - Iteration over a scalar value

FROM s AS V
where s is a scalar value. Then s coerces into the bag << s >>.

This section seems to be mode independent, i.e., coercion always happens.

[johnedquinn]

At the top of Section 5.1.1:

In the following cases the expression in the FROM clause item has the wrong type. Under the type checking option, all of these cases raise an error and the query fails. Under the permissive option, the cases proceed as follows...

[yliuuuu]

Same as above.

[johnedquinn]

See my comment.

[yliuuuu]

Same as above.

[johnedquinn]

See my comment.

[yliuuuu]

Same as above.

[johnedquinn]

See my comment.

[yliuuuu]

Same as above.

[johnedquinn]

See my comment.

[yliuuuu]

Tuple navigation with array notation The expression a[s] is a shorthand for the tuple path navigation a.s when
the expression s is either (a) a string literal or (b) an expression that is explicitly CAST into a string. For example:
{'a': 1, 'b': 2}['a'] ⇔ {'a': 1, 'b':2}.'a' → 1

Not sure what the single quoted 'a' means in our spec. but curious why you think this should return a MISSING...

[johnedquinn]

when the expression s is either (a) a string literal or (b) an expression that is explicitly CAST into a string... If s is not a string literal or an expression that is cast into a string, then a[s] is evaluated as an array path navigation.

So, some_struct['a'] (literal string 'a') results in a path expression. Similarly, some_struct[CAST('a' || 'b' AS STRING)] (explicit cast) results in a path expression.

"If s is not a string literal or an expression that is cast into a string" (like variable references, plus operations, etc), "then a[s] is evaluated as an array path navigation." All of the below evaluate as an array path navigation:

1. some_struct[some_variable]
2. some_struct[1 + 1]
3. some_struct['hello' || ', world']

[yliuuuu]

Gotya. So test_struct['unambiguous_variable'] => 'this is unambiguous_lookup_field'`. And the test case is missing single quote here. Is this understanding correct?

[johnedquinn]

Well, I think the intention of the test is a bit different. unambiguous_variable is a global variable pointing to some string, and I believe the original intention was to test that the underlying value that the variable points to can be used to key into structs -- though that assumption is wrong according to the specification.

[yliuuuu]

Same as above.

[johnedquinn]

See comment.

[yliuuuu]

Same as above.

[johnedquinn]

See comment.

[yliuuuu]

Thanks for clarifying.

[yliuuuu]

Nonblocking: but we can think of path navigation as a function that is not nullCall?