Re: GROUP BY checks inadequate when set returning functions in column list

Chris Travers <chris(at)metatrontech(dot)com> writes:
> On Wed, Aug 22, 2012 at 8:04 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> Chris Travers <chris(at)metatrontech(dot)com> writes:
> mtech_test=# explain analyze select (account_heading__list()).* group by accno

>> Hm, that really ought to throw an error, since you have ungrouped
>> columns in the result. Not sure why it doesn't.

> Yeah, that was my point. I don't know if it is worth fixing but
> always better to report.

I looked into this, and found that the query basically expands to

SELECT (func()).field1, (func()).field2, (func()).field3, ... GROUP BY 2;

There are no Vars in this query; only FuncExprs and FieldSelects.
So that's why the check for ungrouped variables isn't complaining.
To make it complain, we'd have to have a notion that the different
occurrences of the function are generating related columns of a row,
which is something that quite disappears in the *-expansion.

As I said before, this isn't really an area that anybody is excited
about changing --- it's all legacy behavior, and if we change it
we're more likely to get complaints from people whose code broke
than compliments from people who can now use it for something.
Eventually I think SRFs in the targetlist will be deprecated in
favor of LATERAL constructs, though it will be a very long time
before we could consider removing the feature altogether.

regards, tom lane