Re: Improving inferred query column names

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

In response to

Responses

Browse pgsql-hackers by date

  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