From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Peter Eisentraut <peter(dot)eisentraut(at)enterprisedb(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Improving inferred query column names |
Date: | 2023-02-22 20:38:48 |
Message-ID: | 20230222203848.jv2bnpbx57gevl2h@awork3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
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)".
> We had a colleague look into this a little while ago, and it got pretty
> tedious to implement this for all the expression types.
Hm, any chance that colleague could be pointed at this discussion and chime
in? It doesn't immediately look that hard to do substantially better than
today. Of course there's an approximately endless amount of effort that could
be poured into this, but even some fairly basic improvements seem like a big
win.
> And, you know, the bikeshedding ...
Indeed. I already started above :)
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2023-02-22 20:40:22 | Re: Improving inferred query column names |
Previous Message | Andres Freund | 2023-02-22 20:33:45 | Re: pg_regress: Treat child process failure as test failure |