You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@iotdb.apache.org by Bryan Yang <y5...@gmail.com> on 2026/06/03 03:34:17 UTC

Request to work on Part 1 of #17797: SELECT aliases in GROUP BY / ORDER BY

*Hi Apache IoTDB Community,*

I would like to work on Part 1 of issue #17797:
https://github.com/apache/iotdb/issues/17797

Issue title:
[Feature] Allow referencing SELECT column aliases in GROUP BY / ORDER BY
(and support lateral column alias in SELECT)

For this PR, I plan to focus only on Part 1: allowing SELECT column aliases
to be referenced in GROUP BY and ORDER BY in the table model SQL analyzer.

I will leave Part 2, lateral column alias references inside the SELECT
list, out of scope for this PR and handle it in a separate follow-up PR
after Part 1 is merged.

The intended behavior is:

1. GROUP BY can reference a SELECT alias when the name does not resolve to
an input column first.

Example:

SELECT date_bin(1h, time) AS hour_time, AVG(temperature) AS avg_temp
FROM table1
GROUP BY hour_time
ORDER BY hour_time;

This should be analyzed as if the user wrote:

SELECT date_bin(1h, time) AS hour_time, AVG(temperature) AS avg_temp
FROM table1
GROUP BY date_bin(1h, time)
ORDER BY date_bin(1h, time);

2. ORDER BY can reference a SELECT alias.

3. Existing behavior should remain unchanged, including:

GROUP BY 1
ORDER BY 1
GROUP BY date_bin(1h, time)
ORDER BY AVG(temperature)

4. For name collisions, I plan to follow the convention mentioned in the
issue:

GROUP BY prefers the input column.
ORDER BY prefers the SELECT output alias.

5. Aliases will not be introduced into WHERE or HAVING in this PR.

6. GROUP BY alias resolution will still run the existing semantic checks
after alias expansion, so an alias whose expression contains aggregate,
window, or grouping functions should be rejected as a GROUP BY key.

I plan to add tests for:

- GROUP BY alias
- ORDER BY alias
- alias/input-column collision behavior
- duplicate alias ambiguity
- aggregate alias used in GROUP BY should fail
- existing ordinal and full-expression references should keep working
- SELECT DISTINCT with ORDER BY alias, if applicable

Could you please assign Part 1 of this issue to me?

Thanks,
Bryan Yang(杨易达)

Re: Request to work on Part 1 of #17797: SELECT aliases in GROUP BY / ORDER BY

Posted by Yuan Tian <ja...@gmail.com>.
Hi Bryan,


Thanks for your interest on this issue, I've assigned it to you.


Best regards,
--------------------
Yuan Tian


On Wed, Jun 3, 2026 at 11:35 AM Bryan Yang <y5...@gmail.com> wrote:

> *Hi Apache IoTDB Community,*
>
> I would like to work on Part 1 of issue #17797:
> https://github.com/apache/iotdb/issues/17797
>
> Issue title:
> [Feature] Allow referencing SELECT column aliases in GROUP BY / ORDER BY
> (and support lateral column alias in SELECT)
>
> For this PR, I plan to focus only on Part 1: allowing SELECT column aliases
> to be referenced in GROUP BY and ORDER BY in the table model SQL analyzer.
>
> I will leave Part 2, lateral column alias references inside the SELECT
> list, out of scope for this PR and handle it in a separate follow-up PR
> after Part 1 is merged.
>
> The intended behavior is:
>
> 1. GROUP BY can reference a SELECT alias when the name does not resolve to
> an input column first.
>
> Example:
>
> SELECT date_bin(1h, time) AS hour_time, AVG(temperature) AS avg_temp
> FROM table1
> GROUP BY hour_time
> ORDER BY hour_time;
>
> This should be analyzed as if the user wrote:
>
> SELECT date_bin(1h, time) AS hour_time, AVG(temperature) AS avg_temp
> FROM table1
> GROUP BY date_bin(1h, time)
> ORDER BY date_bin(1h, time);
>
> 2. ORDER BY can reference a SELECT alias.
>
> 3. Existing behavior should remain unchanged, including:
>
> GROUP BY 1
> ORDER BY 1
> GROUP BY date_bin(1h, time)
> ORDER BY AVG(temperature)
>
> 4. For name collisions, I plan to follow the convention mentioned in the
> issue:
>
> GROUP BY prefers the input column.
> ORDER BY prefers the SELECT output alias.
>
> 5. Aliases will not be introduced into WHERE or HAVING in this PR.
>
> 6. GROUP BY alias resolution will still run the existing semantic checks
> after alias expansion, so an alias whose expression contains aggregate,
> window, or grouping functions should be rejected as a GROUP BY key.
>
> I plan to add tests for:
>
> - GROUP BY alias
> - ORDER BY alias
> - alias/input-column collision behavior
> - duplicate alias ambiguity
> - aggregate alias used in GROUP BY should fail
> - existing ordinal and full-expression references should keep working
> - SELECT DISTINCT with ORDER BY alias, if applicable
>
> Could you please assign Part 1 of this issue to me?
>
> Thanks,
> Bryan Yang(杨易达)
>