morrySnow opened a new pull request, #67812:
URL: https://github.com/apache/doris/pull/67812
### What problem does this PR solve?
Problem Summary:
A scalar subquery that exposes one expression can be rejected as returning
two columns when an aggregate is used only by its `HAVING` clause.
For example:
```sql
CREATE TABLE t (id SMALLINT) DISTRIBUTED BY RANDOM PROPERTIES
('replication_num' = '1');
INSERT INTO t VALUES (1);
SELECT (SELECT 1 FROM t HAVING SUM(id) > 0);
```
The fill-up analysis phase adds aggregate and missing-slot expressions to an
internal project so that `HAVING` and `ORDER BY` can resolve them. In the
aggregate path, it did not restore the original project afterwards. The helper
aggregate therefore leaked into the public output, and scalar-subquery
validation reported `Found 2`.
The rule now always adds a final project with the original output after
`HAVING` and `ORDER BY` consume their helper slots. This keeps internal
dependencies available during analysis while preserving the query's public
output contract.
Tests cover the valid scalar subquery, an empty result caused by `HAVING`,
and a genuine two-column scalar subquery that must still be rejected.
### Release note
Fix false multi-column errors for scalar subqueries whose aggregate appears
only in `HAVING`.
### Check List (For Author)
- Test: Unit Test and Regression Test
- Behavior changed: Yes. Internal helper slots no longer appear in query
output.
- Does this need documentation: No
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
