[
https://issues.apache.org/jira/browse/FLINK-3723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15241241#comment-15241241
]
Fabian Hueske commented on FLINK-3723:
--------------------------------------
I am still unsure about this proposal:
Pros of splitting {{select}} into {{agg}} for aggregations and {{select}}
projections:
- simplified code because this representation is closer to Calcite's internal
representation
- better separation of functionality, e.g., for Table API on streams
- might be easier to use
Cons:
- select-only is closer to standard SQL
- requires an additional Table API operator in certain situations
- rather complex code to separate expressions from aggregations
What do you think [~twalthr], [~vkalavri], [~chengxiang li], [~aljoscha]?
Any pros or cons if forgot to mention [~yijieshen]?
> Aggregate Functions and scalar expressions shouldn't be mixed in select
> -----------------------------------------------------------------------
>
> Key: FLINK-3723
> URL: https://issues.apache.org/jira/browse/FLINK-3723
> Project: Flink
> Issue Type: Improvement
> Components: Table API
> Affects Versions: 1.0.1
> Reporter: Yijie Shen
>
> When we type {code}select deptno, name, max(age) from dept group by
> deptno;{code} in calcite or Oracle, it will complain {code}Expression 'NAME'
> is not being grouped{code} or {code}Column 'dept.name' is invalid in the
> select list because it is not contained in either an aggregate function or
> the GROUP BY clause.{code} because of the nondeterministic result.
> Therefore, I suggest to separate the current functionality of `select` into
> two api, the new `select` only handle scalar expressions, and an `agg` accept
> Aggregates.
> {code}
> def select(exprs: Expression*)
> def agg(aggs: Aggregation*)
> ....
> tbl.groupBy('deptno)
> .agg('age.max, 'age.min)
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
