Enable the IN clause to also compare the value of single-pair structs

[johnedquinn]

Related Issue

Related to #524

Description

Allows the IN clause to compare the value of single-pair structs, to maintain compatibility with SQL-92. To do this, it is necessary to make two changes:

• If the rightOp is already computed as a sequence of single-pair structs (where each pair's value is a literal), we can use the optimized approach and immediately compare with that value.
• If the rightOp is not computed (for example: another SELECT returning a bag/list of structs, or a bag of structs with pairs that contain un-evaluated values), then we need to evaluate.

Examples

SELECT age FROM << { 'name': 'John', 'age': 22 } >> WHERE name IN (SELECT name FROM <<{ 'name': 'John' }>>)

should result in:

<<
  { age: 22 }
>>

Notice

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

[dlurton]

This change only applies to EvaluatingCompiler. Since we're intending to remove the EvaluatingCompiler at some point and its replacement isn't complete yet, there are two options:

1. Make this change in EvaluatingCompiler and its replacement (PhysicalBexprToThunkConverter, introduced in Add Plan Evaluator #592 and will be merged to main today if all goes well).
2. Make this change in only PhysicalBexprToThunkConverter, which means this fix will have limited applicability until the PhysicalBexprToThunkConverter is complete and EvaluatingCompiler is removed.

[johnedquinn]

This change only applies to EvaluatingCompiler. Since we're intending to remove the EvaluatingCompiler at some point and its replacement isn't complete yet, there are two options:

1. Make this change in EvaluatingCompiler and its replacement (PhysicalBexprToThunkConverter, introduced in Add Plan Evaluator #592 and will be merged to main today if all goes well).
2. Make this change in only PhysicalBexprToThunkConverter, which means this fix will have limited applicability until the PhysicalBexprToThunkConverter is complete and EvaluatingCompiler is removed.

@dlurton -- Since this is working on a feature branch off of main, do you think it would make sense to create a separate PR to add to PhysicalBexprToThunkConverter? Then, this one can be merged immediately on approval, and I can work on merging to the other branch? Unless, of course, the other branch is expected to merge by EOD. Then, I'll just park this, pull once other is merged, then add to PhysicalBexprToThunkConverter and merge in the same PR later. Whatever works.

[dlurton]

@johnedquinn I am hoping it can be merged by EOD today but that will depend on getting the approval of @alancai98

I would not make that separate PR due to the possibility of it being "inadvertently deprioritized".

Annnnnnnnd... it looks like he just approved it. I'll merge shortly...

[johnedquinn]

@dlurton -- ACK. I'll park this and wait for the merge to main.

Action items:

• once Merge physical plan evaluator and basic planner to main #612 is merged to main, I'll pull and add my changes for the new evaluator compiler

[johnedquinn]

Accidentally merged all of the new changes in main into this feature branch. Starting a new one to make it easier for reviewers. Following up with PR #621 .