That is a good idea for simple cases, I'm just curious how it would look like for more complex cases (you can have all kinds of expressions as parameters for aggregate function calls).
If it works only for simple cases, I think it would be confusing and not very helpful.
Wouldn't it make more sense to just deduplicate the names by adding numerical postfixes, like sum_1, sum_2?
For backwards compatibility I guess you can have a GUC flag controlling that behavior that can be set into backwards compatibility mode if required.
The previous functionality can be declared deprecated and removed (with the flag) once the current version becomes unsupported.
(or with a different deprecation policy, I'm not sure what is the general rule for breaking changes and deprecation currently).
If there is a clearly defined deprecation policy and a backwards compatibility option, it should be good, no? Just my 2 cents.
-Vladimir Churyukin
Hi,
A common annoyance when writing ad-hoc analytics queries is column naming once
aggregates are used.
Useful column names:
SELECT reads, writes FROM pg_stat_io;
column names: reads, writes
Not useful column names:
SELECT SUM(reads), SUM(writes) FROM pg_stat_io;
column names: sum, sum
So i often end up manually writing:
SELECT SUM(reads) AS sum_reads, SUM(writes) AS sum_writes, ... FROM pg_stat_io;
Of course we can't infer useful column names for everything, but for something
like this, it should't be too hard to do better. E.g. by combining the
function name with the column name in the argument, if a single plain column
is the argument.
I think on a green field it'd be clearly better to do something like the
above. What does give me pause is that it seems quite likely to break
existing queries, and to a lesser degree, might break applications relying on
inferred column names
Can anybody think of a good way out of that? It's not like that problem is
going to go away at some point...
Greetings,
Andres Freund
