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.

[alancai98]

Perhaps we can clarify this behavior in the spec or some other document before changing the behavior? As the PartiQL spec is currently written, it's unclear to me if these cases would be an error in strict mode.

For most functions/operations (other than equality, IS MISSING, and some boolean ops), a data type mismatch would result in an error in strict mode and return MISSING in permissive. E.g.

• ABS('some string')
  • MISSING in permissive
  • error in strict

I guess it's less clear to me if a MISSING literal denotes the same erroring behavior. E.g.

• ABS(MISSING)
  • MISSING in permissive
  • error or MISSING in strict?

Following @jpschorr's analogy of signaling and quiet NaNs, the MISSING would have two different types

• Signaling MISSING -> data type mismatches, path expression yielding no field
• Quiet MISSING -> literal MISSING in the query text or input data

If we are following this signaling vs quiet model, then I would think quiet MISSINGs as a function argument would return a quiet MISSING in strict mode.

[alancai98]

It's interesting that the spec is very explicit for the cases in which strict mode would give an error on MISSING like Section 5.1.1 Mistyping Cases but is less explicit for function arguments in section 7.

The spec does give a direct example using the MISSING literal in an operation:

Example 28. Each one of these expressions returns MISSING: 5 + missing

but it's unclear whether this applies to both permissive and strict modes.

[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.