Re: Improving inferred query column names

On 11.02.23 20:24, Andres Freund wrote:
> 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...

I think we should just do it and not care about what breaks. There has
never been any guarantee about these.

FWIW, "most" other SQL implementations appear to generate column names like

SELECT SUM(reads), SUM(writes) FROM pg_stat_io;
column names: "SUM(reads)", "SUM(writes)"

(various capitalization of course).

We had a colleague look into this a little while ago, and it got pretty
tedious to implement this for all the expression types. And, you know,
the bikeshedding ...

But I'm all in favor of improving this.