[
https://issues.apache.org/jira/browse/FLINK-11447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16758450#comment-16758450
]
sunjincheng commented on FLINK-11447:
-------------------------------------
Thanks for the [~twalthr] [~dawidwys] [~hequn8128] lively discussion！
Hi [~hequn8128] Thank you very much for reviewing the information of many
lateralTables!
That's true, there are clear definitions of lateral in several commonly used
databases, e.g.:
* Postresql Lateral will join a subquery, e.g.:
{code:java}
SELECT * FROM tab, lateral (select ...) alias ...`{code}
* Hive Lateral will join the VIEW keyword, then UDTF, e.g:
{code:java}
SELECT * FROM tab LATERAL VIEW udtf(..) ...{code}
* SQL Server uses Cross Apply, but essentially adds a subquery, e.g.:
{code:java}
SELECT * FROM tableA a CROSS APPLY (select ...) alias{code}
Although there are certain differences in grammar, here is essentially the
right side parameter of join is Table.
So，I think the method `join(String)` should not be defined in TableAPI which we
have reached a consensus
Then we have two better approach:
Approach 1: Add the new operator `JoinLateral` and `leftOuterJoinLateral`
Approach 2: Add the static method `create(..)` (maybe `createLateralTable(..)`
is better) in table interface;
>From the points of my view, both solutions can solve the UDTF problem of java
>users. About #1 we introduced joinLateral, which shows that the user's
>argument is a udtf (String or Expression), but the semantics are still JOIN.
>There is a little doubt which [~hequn8128] mentioned above.
About #2: we do not need introduce the new operator, but there is also a
problem here that the fieldRefrence of table.create(tenv,
"udtf(fieldRefrence")), i.e: `table.create()` cannot be used independently
(currently new Table("udtf(fieldRefrence") also exists same problem).
I think both of the approach may be the temporary solution to complete the
`flip32`, we may further discuss in the future to find a better solution, such
as we may discuss Table classification, Table, TemporalTable, LateralTable,
etc. So I suggest that we can choose one of them now As soon as possible to
advance the progress of FLIP-32, maybe we can discuss the long-term planning in
the new thread.
What do you think? [~twalthr] [~hequn8128] [~dawidwys] [~dian.fu]
Best, Jincheng
> Deprecate "new Table(TableEnvironment, String)"
> -----------------------------------------------
>
> Key: FLINK-11447
> URL: https://issues.apache.org/jira/browse/FLINK-11447
> Project: Flink
> Issue Type: New Feature
> Components: Table API & SQL
> Reporter: Timo Walther
> Assignee: Dian Fu
> Priority: Major
>
> A more detailed description can be found in
> [FLIP-32|https://cwiki.apache.org/confluence/display/FLINK/FLIP-32%3A+Restructure+flink-table+for+future+contributions].
> Once table is an interface we can easily replace the underlying
> implementation at any time. The constructor call prevents us from converting
> it into an interface.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
