You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@calcite.apache.org by 董剑辉 <mu...@gmail.com> on 2021/12/30 07:22:46 UTC
I have some questions about the offset of the RexRangeRef
I see the following java doc in org.apache.calcite.rex.RexRangeRef, and I
want to ask why return RexInputRef(5,Integer) not RexInputRef(4,Integer)
when create a reference to the DNAME field?
"Reference to a range of columns.
This construct is used only during the process of translating a SQL tree to
a rel/rex tree. Regular rex trees do not contain this construct.
While translating a join of EMP(EMPNO, ENAME, DEPTNO) to DEPT(DEPTNO2,
DNAME) we create RexRangeRef(DeptType,3) to represent the pair of columns
(DEPTNO2, DNAME) which came from DEPT. The type has 2 columns, and
therefore the range represents columns {3, 4} of the input.
Suppose we later create a reference to the DNAME field of this RexRangeRef;
it will return a RexInputRef(5,Integer), and the RexRangeRef will
disappear."
Thank you =)
Re: I have some questions about the offset of the RexRangeRef
Posted by Stamatis Zampetakis <za...@gmail.com>.
The example with RexInputRef(5) is mentioned in the Javadoc of RexRangeRef
[1] and it looks like a typo. As Julian said, it should be RexInputRef(4)
and the type should probably be VARCHAR.
[1]
https://github.com/apache/calcite/blob/8983e7e82ef65c3a72f06305a676cc2998bf72d6/core/src/main/java/org/apache/calcite/rex/RexRangeRef.java#L40
On Thu, Dec 30, 2021 at 10:18 AM Julian Hyde <jh...@gmail.com> wrote:
> Column ordinals are as follows:
>
> 0 EMP.EMPNO
> 1 EMP.ENAME
> 2 EMP.DEPTNO
> 3 DEPT.DEPTNO2
> 4 DEPT.DNAME
>
> So I would expect Calcite to return RexInputRef(4, Integer) for DNAME.
>
> If you’re seeing RexInputRef(5) there is something strange going on in
> your environment (e.g. EMP has more columns than you think).
>
> Julian
>
>
> > On Dec 29, 2021, at 11:22 PM, 董剑辉 <mu...@gmail.com> wrote:
> >
> > I see the following java doc in org.apache.calcite.rex.RexRangeRef, and I
> > want to ask why return RexInputRef(5,Integer) not RexInputRef(4,Integer)
> > when create a reference to the DNAME field?
> > "Reference to a range of columns.
> > This construct is used only during the process of translating a SQL tree
> to
> > a rel/rex tree. Regular rex trees do not contain this construct.
> > While translating a join of EMP(EMPNO, ENAME, DEPTNO) to DEPT(DEPTNO2,
> > DNAME) we create RexRangeRef(DeptType,3) to represent the pair of columns
> > (DEPTNO2, DNAME) which came from DEPT. The type has 2 columns, and
> > therefore the range represents columns {3, 4} of the input.
> > Suppose we later create a reference to the DNAME field of this
> RexRangeRef;
> > it will return a RexInputRef(5,Integer), and the RexRangeRef will
> > disappear."
> > Thank you =)
>
>
Re: I have some questions about the offset of the RexRangeRef
Posted by Julian Hyde <jh...@gmail.com>.
Column ordinals are as follows:
0 EMP.EMPNO
1 EMP.ENAME
2 EMP.DEPTNO
3 DEPT.DEPTNO2
4 DEPT.DNAME
So I would expect Calcite to return RexInputRef(4, Integer) for DNAME.
If you’re seeing RexInputRef(5) there is something strange going on in your environment (e.g. EMP has more columns than you think).
Julian
> On Dec 29, 2021, at 11:22 PM, 董剑辉 <mu...@gmail.com> wrote:
>
> I see the following java doc in org.apache.calcite.rex.RexRangeRef, and I
> want to ask why return RexInputRef(5,Integer) not RexInputRef(4,Integer)
> when create a reference to the DNAME field?
> "Reference to a range of columns.
> This construct is used only during the process of translating a SQL tree to
> a rel/rex tree. Regular rex trees do not contain this construct.
> While translating a join of EMP(EMPNO, ENAME, DEPTNO) to DEPT(DEPTNO2,
> DNAME) we create RexRangeRef(DeptType,3) to represent the pair of columns
> (DEPTNO2, DNAME) which came from DEPT. The type has 2 columns, and
> therefore the range represents columns {3, 4} of the input.
> Suppose we later create a reference to the DNAME field of this RexRangeRef;
> it will return a RexInputRef(5,Integer), and the RexRangeRef will
> disappear."
> Thank you =)