incorporate result values into the computation of the results of a RecordQueryPlan

[normen662]

Both RelationalExpression and therefore by inheritance RecordQueryPlan have a method

@Nonnull
    Optional<List<? extends Value>> getResultValues();

Currently, every implementor can chose to ignore this method and just return Optional.empty(). This method, however, allows the planner to create derivation graphs, i.e. we can trace down how a result value was computed all the way to the fetch(es) that read data from the database.

For a lot of operations, think filter expressions, this method is almost trivial, we just pull up the columns of the quantifier the filter owns. For SelectExpressions, the Values in the list returned by this method conceptually are the expressions in the select list of a SELECT exp1, exp2, ..., expn FROM T WHERE .... If a RelationalExpression computes something very complicated, it can also just choose to return BaseValue or ComputedValue which will cause the derivation graph to terminate.

It would be beneficial to sweep over the code base and provide basic implementations of this method for all expressions and plans we have today. Second, for plans, we should think about incorporating the Values eval into the eval of the RecordQueryPlan. So for instance, unions and intersections can benefit from that orthogonalization.

[hatyo]

This is also required to properly derive (named) grouping columns, for example:

SELECT x, MAX(c) FROM t GROUP BY a AS x;

The method GroupByExpression#computeRequestOrdering should return (a) as ordering requirement for group by, however it currently returns (x) causing the query to fail even if we have a compatible index on (a).