Re: Improving inferred query column names

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Improving inferred query column names
Дата
Msg-id 20230222203848.jv2bnpbx57gevl2h@awork3.anarazel.de
обсуждение исходный текст
Ответ на Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Ответы Re: Improving inferred query column names  (Peter Eisentraut <peter.eisentraut@enterprisedb.com>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: pg_regress: Treat child process failure as test failure
Следующее
От: Andres Freund
Дата:
Сообщение: Re: Improving inferred query column names