[
https://issues.apache.org/jira/browse/CALCITE-5144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17535824#comment-17535824
]
xuyang commented on CALCITE-5144:
---------------------------------
Hi, [~julianhyde] . I agree with you this is not a bug, and that's the reason I
just tag it as "Improvement".
In SqlToRelConverter the whole RelNode tree is firstly built, and secondly Hint
Propagate Shuttle will propagate the hint from root to leaves. However the
alias information is lost in first step. My point is to use something to record
the alias name in first step and then in second step, how about attaching this
alias as a HINT_ALIAS used in internal to the root node of the subquery in the
Hint Shuttle?
For example, with a sql
{code:java}
select t1.ename from (select * from emp) t1 {code}
we can get the RelNode tree following,
{code:java}
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]]) {code}
What I expect is a tree like
{code:java}
LogicalProject(ENAME=[$1])
LogicalTableScan(table=[[CATALOG, SALES, EMP]], hint=[{ALIAS,
inheritPath=[], optionals=[t1]}]) {code}
What do you think?
> Attaching names as annotations/hints seems to be the wrong direction to go,
> because it will be brittle and will create two different code paths.
It seems that user can conveniently create a RelNode instances manually when
what they want is that the node is a root node of a subquery by adding a
HINT_ALIAS to this node. And this is flexible enough for users.
> Perhaps switch to position-based hints during sql-to-rel.
Actually I'm confused with 'position-based hints', can you take an example?
> table alias is lost by SqlToRelConverter
> ----------------------------------------
>
> Key: CALCITE-5144
> URL: https://issues.apache.org/jira/browse/CALCITE-5144
> Project: Calcite
> Issue Type: Improvement
> Components: core
> Reporter: xuyang
> Priority: Major
>
> I found that in SqlToRelConverter#convertFrom, "AS" only cares about the
> first operand and just ignore the second operand, and this behavior will
> cause the information of the table alias lost.
> The simple SQL is :
> {code:java}
> // code placeholder
> select * from (select * from emp) t1 {code}
> The "t1" will be lost in the final RelNode tree. I think we can retain this
> alias information in the RelNode by some way.
> The real scenarios that require table aliases are Join Hint on subquery just
> like:
> {code:java}
> // code placeholder
> SELECT /*+ USE_NL(v2) */ v2.a
> FROM (select * from test1) v2 join test2 ON v2.a = test2.a {code}
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
