Fixes missing arguments tests

[johnedquinn]

Description

Fixes around 100 missing arguments tests. Previous ones didn't fail in EvalModeError when inputs were the missing value.

Example of one of the tests:

MOD(MISSING, 3)

From the PartiQL Specification (Section 7.1: Inputs with wrong types):

Unlike SQL where typing issues can be detected during query compilation, the permissive option of PartiQL has to define semantics for the case where the inputs of a function are not compatible with the function/predicate arguments. Furthermore, PartiQL facilitates propagating missing input attributes to respective missing output attributes. Alike SQL, all functions have input argument types that they conform to. For example, the function log expects numbers. All functions return MISSING when they input data whose types do not conform to the input argument types. Since no function (other than IS MISSING) has MISSING as an input argument type, it follows that all functions return MISSING when one of their inputs is MISSING.

An important thing to note is the use of "the permissive option of PartiQL has to define semantics for the case where the inputs of a function are not compatible with the function/predicate arguments." It goes on to describe the missing value as inputs, and it defines the behavior in permissive mode. It doesn't explicitly specify what happens in strict mode, however, we may assume the same behavior seen in all other sections of the Specification. See Section 5.1.1 Mistyping Cases, Section 5.2.1 Mistyping cases, Section 4.1 Tuple path evaluation on wrongly typed data, etc.

Another example of throwing errors comes down to the role of schema in type checking. From Section 4.1.1:

In a more important and common case, an PartiQL implementation can utilize the input data schema to prove that a path expression always returns MISSING and thus throw a compile-time error.

NOTE: You should review using "Ignore whitespace". I used auto-formatting on fixed test files using the IDE since the formatting was poor.

License

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

[jpschorr]

Regardless of any of the above, I believe the following must have the same result in permissive and strict modes:

PartiQL> select value t[2] from <<[1,2,MISSING,4]>> as t
   |
==='
<<
  MISSING
>>

We should add a test to ensure this.

[jpschorr]

The crux of the issue here is (as noted above) that the spec talks about 3 sources of 'generated' MISSING values:

1. Failing to interpret a value as a tuple containing a target attribute during path navigation
2. Failing to interpret a value as an array of appropriate length during array navigation
3. Failing to interpret a value as matching a formal argument type to a function

For cases 1 & 2, the spec differentiates strict and permissive mode, saying that:

• permissive mode results in aMISSING value, and
• strict results in an ERROR.

For case 3, the spec says it results in a MISSING value, but doesn't mention any modes, so it is ambiguous whether that means both permissive and strict.

[johnedquinn]

The @partiql/partiql maintainers and @almann discussed this PR. As a summary:

• In strict mode, null and missing values should behave the same. All functions that specify RETURNS NULL ON NULL INPUT return null when one of the arguments is null. The same applies for missing. When one of the arguments is missing, the function should return missing.
• Certain operations (aka tuple path navigation) result in an error. In permissive mode, the error is lowered to a missing value. In strict mode, the error propagates.
• In example 29 of Section 7.1 exists the statement below. In permissive mode, all three cases return missing. In strict mode, the latter two fail.

  Each one of these expressions returns MISSING: 5 + MISSING 5 > 'a' NOT {a:1}

If I have missed anything, please feel free to add more comments.