Re: Improving inferred query column names

On 22.02.23 21:38, Andres Freund wrote:
> On 2023-02-20 16:08:00 +0100, Peter Eisentraut wrote:
>> On 11.02.23 20:24, Andres Freund wrote:
>> 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)"
> Hm, personally I don't like leaving in parens in the names, that makes it
> unnecessarily hard to reference the columns. sum_reads imo is more usable
> than than "SUM(reads)".

If you want something without special characters, the example you gave
is manageable, but what are you going to do with

SELECT a, b, a * b, a / b FROM ...

or

SELECT a, b, SUM(a * b) FROM ...

and so on. What would be the actual rule to produce the output you want?

I think a question here is what "usable" means in this context.

If you want a name that you can refer to (in a client API, for example),
you should give it a name explicitly.

I think the uses for the automatic names are that they look pretty and
meaningful in visual output (psql, pgadmin, etc.). In that context, I
think it is ok to use special characters without limitation, since you
are just going to look at the thing, not type it back in.