Re: Improving inferred query column names

From: Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Improving inferred query column names
Date: 2023-03-02 14:05:51
Message-ID: aacfb782-36ae-cdf8-684b-b618db573b64@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

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.

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Dave Cramer 2023-03-02 14:13:36 Request for comment on setting binary format output per session
Previous Message Amit Langote 2023-03-02 13:52:53 Re: generic plans and "initial" pruning