Eradicates premature failures when visiting error nodes

[johnedquinn]

Relevant Issues

• None

Description

According to the PartiQL Specification:

For example, in the presence of schema validation, an PartiQL query processor can throw a compile-time error when given the path expression {a:1, b:2}.c. 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.

So, this translates to deferring failure until evaluation. While it is sub-optimal, it complies with the specification. We can always change the testing mechanism in the future.

Beyond that, I found that we had some bugs due to throwing errors when we saw unresolved nodes in the PlanTransform. The root cause is that we were appending unresolved nodes to the "causes" list of Rex.Op.Err. Therefore, with the introduction of Rex.Op.Err, yes -- we would temporarily handle errors, however, when we'd visit those errors, we would prematurely fail compilation.

This PR fixes both of the above situations.

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.

[RCHowell]

So, this translates to deferring failure until evaluation.

The specification says most commonly you want to error, but can defer. This is what Yingtao's PR for planner modes handles. I urge that signal mode is the default.

[johnedquinn]

So, this translates to deferring failure until evaluation.

The specification says most commonly you want to error, but can defer. This is what Yingtao's PR for planner modes handles. I urge that signal mode is the default.

The focus of this PR is to bridge the conformance gap (this PR passes an additional 20 tests). The existing conformance tests defer on erroring as does the existing evaluator. To accommodate your suggestion, there are two things I could do:

1. Update the tests to allow for erroring during compilation.
2. Or, add a flag to the engine (not default) to defer on erroring. Then, in the conformance tests runs, I can use the non-default flag to match the functionality of the existing evaluator.

[RCHowell]

I still don't quite understand the purpose here other than conformance tests being wrong. I believe Yingtao's planner work and the compiler implementation are correct.

HOWEVER

I think perhaps we should be making changes in the planner not the compiler.

Here are the Options afaik

1. If we can confirm that the tests are correct, then the fix should go into the planner.
2. If the tests are incorrect, then we can close this and open an issue in partiql-tests