Re: Improving inferred query column names - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Improving inferred query column names
Date
Msg-id 20230222203848.jv2bnpbx57gevl2h@awork3.anarazel.de
Whole thread Raw
In response to Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Responses Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
List 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



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: pg_regress: Treat child process failure as test failure
Next
From: Andres Freund
Date:
Subject: Re: Improving inferred query column names