Adds planning and evaluation support for CTEs

[johnedquinn]

Relevant Issues

• This is a follow-up to Adds parsing and modeling of CTEs #1736.

Description

• Adds planning and evaluation support for CTEs
• On a basic level, this PR:
  • Adds an internal plan node, called With that lies at the top of an ExprQuerySet (Rex). When we go to type this sub-tree, we adjust our environment to include the with clause's elements. In an ideal world, we would immediately type on the conversion from the AST to plan, and we wouldn't need this fairly odd logic, but it is what it is (for now).
  • Related to the above, updates the definition of the internal environment Scope to contain a list of WithListElements. Then, when attempting to resolve variables locally, the scope is able to find the WithListElement's representation (an ExprQuerySet) and return its value. This essentially replaces references to the CTE variables with their definitions. This is what PostgreSQL does when a CTE is referenced once.
• This approach has one main pro: we don't need to update the public plan. Eventually, if we'd like, we may alter this approach with a variety of designs, namely:
  • A wrapper over a relation -- indicating the name of the CTE for further inspection.
  • The current approach, which is what PostgreSQL uses when the CTE is only referenced once.
  • A common CTE available to a sub-plan -- primarily for optimization purposes (memoization of the rows). This is what PostgreSQL uses when the CTE is referenced multiple times.
• This PR does NOT add support for RECURSIVE CTEs nor does it provide support for the with list element's column list. Please see the screenshots at the bottom of this description.

Release Plan

• There are only API additions related to a new kind of PError (one that should have existed before). The new error (DEGREE_VIOLATION_SCALAR_SUBQUERY) is used when the degree of a scalar subquery is not 1. This allows for comprehensive testing of the WITH clause. It is also useful to the end-user.
• There are NO API changes/additions in relation to the plan.
• This will be released as part of v1.1.0. There are NO API changes. Only feature additions.
• As for the release of v1.1.0, I'd like to gain some clarity on whether the with element's optional column list is expected for planning/evaluation. If this is needed, there are a few changes that we'll need to make.

Examples

Below is an example of a CTE embedded within a CTE:

Below is an example of the errors you may encounter:

License Information

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

[jpschorr]

I believe this is the final PR for adding the currently-planned level of CTE support. We should probably update the Changelog.

[jpschorr]

Looks good! I just have a couple of questions and non-blocking comments.

[jpschorr]

-- y should not be able to be referenced.

y is fine, no? It's the x that should not be able to be referenced inside y?

[jpschorr]

Why return Any and not org.partiql.plan.rel.Rel?

[johnedquinn]

In the end, it doesn't matter. These all get cast to Rels.

[johnedquinn]

Merging this, and going to add the minor updates to the release commit.