there are actually few other similar places where the loops are over the
StatementQuery data rather than StatementSpecification one (lines 416,
478). I haven't look whether they are legitimate cases or not though. But
making this method static would expose all these hard to spot places.

On Mon, Feb 25, 2013 at 9:26 PM, Paul A Martel <notifications@github.com>wrote:

> In src/hsqldb19b3/org/hsqldb_voltpatches/StatementQuery.java:
>
> > @@ -494,7 +494,7 @@ else if ((otherCol.opType != OpTypes.SIMPLE_COLUMN) &&
> >          query.children.add(scans);
> >          assert(scans != null);
> >
> > -        for (RangeVariable rangeVariable : rangeVariables)
> > +        for (RangeVariable rangeVariable : select.rangeVariables)
>
> I see. Good catch. That makes me want to take the preventative measure of
> factoring out much of this select-specific processing into its own method.
> Either a QuerySpecification member -- look at all those extra "select."s
> OR, to be a little less disruptive, a static member of StatementQuery,
> preventing any "accidental" use of other StatementQuery members.
>
> BTW, I was reminded while researching this comment that I had intended to
> eliminate the scan_columns attribute as largely redundant with other parts
> of the voltXML tree. I'd like to replace it with behavior in
> AbstractParsedStmt that tracks each query's scans' column references as
> they are instantiated/resolved in their various AbstractExpression trees on
> the "other side". Maybe we'll get another chance at that when it gets
> redone for self-joins.
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/alexeevm/voltdb/pull/4/files#r3146968>
> .
>