Dean Rasheed <dean.a.rasheed@gmail.com> writes:
> One final case that could possibly be improved is this one from aggregates.out:
> explain (verbose, costs off)
> select array(select sum(x+y) s
> from generate_series(1,3) y group by y order by s)
> from generate_series(1,3) x;
> QUERY PLAN
> -------------------------------------------------------------------
> Function Scan on pg_catalog.generate_series x
> Output: ARRAY(SubPlan 1)
> Function Call: generate_series(1, 3)
> SubPlan 1
> -> Sort
> Output: (sum((x.x + y.y))), y.y
> Sort Key: (sum((x.x + y.y)))
> -> HashAggregate
> Output: sum((x.x + y.y)), y.y
> Group Key: y.y
> -> Function Scan on pg_catalog.generate_series y
> Output: y.y
> Function Call: generate_series(1, 3)
> ARRAY operates on a SELECT with a single targetlist item, but in this
> case it looks like the subplan output has 2 columns, which might
> confuse people.
I'm inclined to leave that alone. The actual source sub-SELECT
could only have had one column, so no real confusion is possible.
Yeah, there's a resjunk grouping column visible in the plan as well,
but those exist in many other queries, and we've not gotten questions
about them.
(Perhaps some documentation about junk columns needs to be added?
I'm not eager to write it though.)
I had actually had a similar thought about sticking ".col1" onto
EXPR_SUBLINK cases, but I concluded it was mostly pedantry.
Nobody's likely to get confused.
regards, tom lane
