Adds IS predicate as special operator

[RCHowell]

Description

The IS Predicate is a pair of value (NULL and MISSING) predicates and a type check predicate which encapsulate the SQL and with the necessary generalization for semi-structured data.

Syntax

<is predicate>
     ::= <null predicate>
      | <missing predicate>
      | <type predicate>

<null predicate> ::= <expr> IS [ NOT ] NULL

<missing predicate ::= <expr> IS [ NOT ] MISSING

<type predicate>
    ::= <expr> IS [ NOT ] OF '(' <type list> ')'
      | <expr> IS [ NOT ] <type>

Notes

• IS NULL appears in both the PartiQL Specification and is SQL-99 standard.
• IS MISSING appears in the PartiQL Specification, but is not SQL-99 standard.
• IS OF is SQL-99 standard, but is not in the PartiQL Specification
• IS TUPLE appears in the PartiQL Specification and is not SQL-99 standard.
• Today’s partiql-lang-kotlin does not support IS OF syntax
• Today’s partiql-lang-kotlin does not support IS with structural types.
• NULL IS will return NULL

Questions?

• What about checking if a REAL value is a DOUBLE PRECISION and visa-versa?

Other Information

• Updated Unreleased Section in CHANGELOG: NO
• Any backward-incompatible changes? YES
• 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.

[github-actions]

Conformance comparison report-Cross Engine

	Base (legacy)	eval	+/-
% Passing	92.49%	92.26%	-0.24%
✅ Passing	5433	5420	-13
❌ Failing	441	455	14
🔶 Ignored	0	0	0
Total Tests	5874	5875	1
Number passing in both: 5159

Number failing in both: 180

Number passing in legacy engine but fail in eval engine: 275

Number failing in legacy engine but pass in eval engine: 261
⁉️ CONFORMANCE REPORT REGRESSION DETECTED ⁉️
The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.
261 test(s) were failing in legacy but now pass in eval. Before merging, confirm they are intended to pass.
The complete list can be found in GitHub CI summary, either from Step Summary or in the Artifact.

Conformance comparison report-Cross Commit-LEGACY

	Base (73db367)	54d965f	+/-
% Passing	92.49%	92.49%	0.00%
✅ Passing	5433	5433	0
❌ Failing	441	441	0
🔶 Ignored	0	0	0
Total Tests	5874	5874	0
Number passing in both: 5433

Number failing in both: 441

Number passing in Base (73db367) but now fail: 0

Number failing in Base (73db367) but now pass: 0

Conformance comparison report-Cross Commit-EVAL

	Base (73db367)	54d965f	+/-
% Passing	92.22%	92.26%	0.03%
✅ Passing	5418	5420	2
❌ Failing	457	455	-2
🔶 Ignored	0	0	0
Total Tests	5875	5875	0
Number passing in both: 5418

Number failing in both: 455

Number passing in Base (73db367) but now fail: 1

Number failing in Base (73db367) but now pass: 3
⁉️ CONFORMANCE REPORT REGRESSION DETECTED ⁉️. The following test(s) were previously passing but now fail:

Click here to see

• Example 6 — Value Coercion, compileOption: LEGACY

The following test(s) were previously failing but now pass. Before merging, confirm they are intended to pass:

Click here to see

• Example 6 — Value Coercion, compileOption: LEGACY

• selectDistinctStarMixed, compileOption: LEGACY

• selectDistinctStarUnknowns, compileOption: LEGACY

[johnedquinn]

Suggested change

	val r = when (type.kind) {
	return Datum.bool(v.type == type)

I almost feel that <expr> IS <type> is useful for evaluating the exact runtime type in the gradual typing use-case. For example:

CREATE FUNCTION foo(a INT, b INT)
  RETURNS DECIMAL
  SPECIFIC foo_1
  RETURN ...;

CREATE FUNCTION foo(a SMALLINT, b STRING)
  RETURNS FLOAT
  SPECIFIC foo_2
  RETURN ...;

SELECT
  CASE
    WHEN intValue IS INT THEN foo(intValue, 5)
    WHEN intValue IS SMALLINT THEN foo(intValue, 'hello')
  END
FROM tbl AS t
LET t.a AS intValue

Let's assume that the static type of tbl is DYNAMIC. At runtime, let's assume that t.a is of type SMALLINT. According to the logic below, SMALLINT still passes the IS INT predicate. Therefore foo_1 will be invoked. I feel as if foo_2 should have been invoked.

[RCHowell]

Here are some examples where this suggestion may not work.

1. Checking if we can cast.

WHEN x IS INT CAST(x AS INT) ELSE 0

2. The suggestion doesn't align with our conformance tests, perhaps decimals are an exception?

Example conformance tests.

0.001 is DECIMAL(3,3) -- left-hand-side is typed as an arbitrary decimal today

In your example all decimal parameters would be ignored so we can't do that — the rules for decimal type checking should align with integer. Aka IS -> true when the exact numeric type has precision less-than-or-equal-to the given type.

4. But then all parameterized things will be special cases.

-- this implementation
"abc" IS CHAR     -- > false
"abc" IS CHAR(1)     -- > false
"abc" IS CHAR(3)   -- > true


-- suggestion
"abc" IS CHAR     -- > true
"abc" IS CHAR(1)     -- > true?
"abc" IS CHAR(3)   -- > true

The same logic applies to all parameterized things - why not use the parameters?

5. Perhaps IS cannot take parameters only kinds, but then it doesn't align with your exact runtime type checking.

You wouldn't be able to check any decimals, chars/varchar lengths, etc.