Re: Improving inferred query column names

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

On Sat, Feb 11, 2023 at 11:24 AM Andres Freund <andres(at)anarazel(dot)de> wrote:

> 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
>
>
>