[
https://issues.apache.org/jira/browse/CALCITE-703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Julian Hyde updated CALCITE-703:
--------------------------------
Description:
AggregateCall has a name field, and it is currently used to populate the name
of the output field. But it makes as much sense for an aggregate call, say
{{COUNT( x )}}, to have a name as for a call to a regular operator, say {{x +
y}}.
Obsolete the name field, and provide another means to specify the output field
names of an Aggregate.
Here is a proposal:
* Add {{RelDataType rowType}} argument to the constructor of Aggregate (and
sub-types such as LogicalAggregate)
* Add {{Map<Integer, String> fieldNames}} argument to {{Aggregate#create}}; if
there is not an entry for a particular output field ordinal, uses the current
rule (input field for grouping fields, "i$" + grouping field for indicators,
"f$" + n for aggregate calls).
* Remove the {{String name}} argument from AggregateCall constructor.
* Existing methods will remain, deprecated, to be removed just before 2.0.
Thus if you currently create an AggregateCall with a name, you would instead
pass that name in via the fieldNames map. Aggregate would assign a row-type
during construction.
was:
AggregateCall has a name field, and it is currently used to populate the name
of the output field. But it makes as much sense for an aggregate call, say
{{COUNT(x)}}, to have a name as for a call to a regular operator, say {{x + y}}.
Obsolete the name field, and provide another means to specify the output field
names of an Aggregate.
Here is a proposal:
* Add {{RelDataType rowType}} argument to the constructor of Aggregate (and
sub-types such as LogicalAggregate)
* Add {{Map<Integer, String> fieldNames}} argument to {{Aggregate#create}}; if
there is not an entry for a particular output field ordinal, uses the current
rule (input field for grouping fields, "i$" + grouping field for indicators,
"f$" + n for aggregate calls).
* Remove the {{String name}} argument from AggregateCall constructor.
* Existing methods will remain, deprecated, to be removed just before 2.0.
Thus if you currently create an AggregateCall with a name, you would instead
pass that name in via the fieldNames map. Aggregate would assign a row-type
during construction.
> Obsolete AggregateCall.name
> ---------------------------
>
> Key: CALCITE-703
> URL: https://issues.apache.org/jira/browse/CALCITE-703
> Project: Calcite
> Issue Type: Bug
> Reporter: Julian Hyde
> Assignee: Julian Hyde
>
> AggregateCall has a name field, and it is currently used to populate the name
> of the output field. But it makes as much sense for an aggregate call, say
> {{COUNT( x )}}, to have a name as for a call to a regular operator, say {{x +
> y}}.
> Obsolete the name field, and provide another means to specify the output
> field names of an Aggregate.
> Here is a proposal:
> * Add {{RelDataType rowType}} argument to the constructor of Aggregate (and
> sub-types such as LogicalAggregate)
> * Add {{Map<Integer, String> fieldNames}} argument to {{Aggregate#create}};
> if there is not an entry for a particular output field ordinal, uses the
> current rule (input field for grouping fields, "i$" + grouping field for
> indicators, "f$" + n for aggregate calls).
> * Remove the {{String name}} argument from AggregateCall constructor.
> * Existing methods will remain, deprecated, to be removed just before 2.0.
> Thus if you currently create an AggregateCall with a name, you would instead
> pass that name in via the fieldNames map. Aggregate would assign a row-type
> during construction.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
