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