The whole purpose of the recursive call was to 'register' (add to the
cache) all tables/aliases pairs from the output schema. But, it looks like
I re-arranged the code to register table/alias pair while parsing tables
and the whole recursive call is obsolete anyway. I removed it.

There is a small problem though
select A, C FROM R1 A JOIN R1 B USING(A)

the output schema columnref element for a column mentioned in the USING
expression won't have a table alias mentioned. So, the TVE for that column
would have table alias set to the table name in the output schema. While
resolving column indexes for the projection node, this TVE would be matched
against the TVEs from the projection's input schema, where there will be
two TVEs for the column A (for each table/alias combination R1/A and R1/B)
and non of them matching the output TVE because of the different table
alias name. The index will be set to -1 as a result. I am still trying to
fix it. The information what tables/aliases are actually behind the column
is there (as nested columnref elements) but we discard it. It almost looks
like that SchemaColumn should also have a list of nested SchemaColumn
element just for that case. What do you think?

By the way, should it be a check (assert) that the column index is actually
resolved and not equal to -1? Right now
ProjectionPlanNode.resolveColumnIndexesUsingSchema quietly sets to -1
resulting in the runtime EE error.

Mike




On Wed, Sep 25, 2013 at 2:45 PM, Paul A Martel <notifications@github.com>wrote:

> In src/frontend/org/voltdb/planner/ParsedSelectStmt.java:
>
> > -            else
> > -            {
> > -                // XXX hacky, assume all non-column refs come from a temp table
> > -                col.tableName = "VOLT_TEMP_TABLE";
> > -                col.columnName = "";
> > -            }
> > -            // This index calculation is only used for sanity checking
> > -            // materialized views (which use the parsed select statement but
> > -            // don't go through the planner pass that does more involved
> > -            // column index resolution).
> > -            col.index = displayColumns.size();
> > -
> > -            insertAggExpressionsToAggResultColumns(aggregationList, col);
> > -            if (aggregationList.size() >= 1) {
> > -                hasAggregateExpression = true;
> > +                parseDisplayColumnReferences(child, isDistributed);
>
> This call is throwing away its result -- should the call to
> "displayColumns.add(col);" above me moved into the recursive function?
> Is it correct to process child columnrefs and then fall through to ALSO
> process the parent columnref?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/alexeevm/voltdb/pull/5/files#r6581562>
> .
>