I think so. The * column had been added to the container after currentReader.next() was called.
How do we priority this issue ? On Sun, May 10, 2015 at 4:09 PM, Jacques Nadeau <[email protected]> wrote: > I think it must be an issue in the ExtendedJsonReader (which is used by the > ValuesRel). It is probably the same as: > > https://issues.apache.org/jira/browse/DRILL-2906 > > Fixing 2906 should fix this. Can you try to determine issue? > > On Sun, May 10, 2015 at 4:03 PM, Hsuan Yi Chu <[email protected]> wrote: > > > I tried a query which has a pattern: > > > > column IN (1212 + 1, 1212 + 2, 1212) > > > > For the tuple, Calcite makes a plan like > > > > UnionAll(all=[true]) > > UnionAll(all=[true]) > > Project(EXPR$0=[+(1212, 1)]) > > Values > > Project(EXPR$0=[+(1212, 2)]) > > Values > > Values > > > > And I found one surprising thing. At planning time, ValuesPrel has the > > correct RelRecordType > > > > However, at execution, the schema of the recordbatch from scanning Values > > is [`ZERO`(BIGINT: OPTIONAL), `*`(BIGINT: OPTIONAL)]. > > > > I cannot make sense out of the second column (i.e., *). Does that serve > > special purpose? Or is it a bug which we should try to remove? Its > > existence causes some issues for UNION ALL. > > >
