Re: Improving inferred query column names

2023-03-02 Thread Peter Eisentraut
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

Re: Improving inferred query column names

2023-02-23 Thread Joe Conway
On 2/22/23 23:03, Tom Lane wrote: Andres Freund writes: We could just do something like printing __. So something like avg(reltuples / relpages) would end up as avg_reltuples_float48div_relpages. Whether that's worth it, or whether column name lengths would be too painful, IDK. I think you'd

Re: Improving inferred query column names

2023-02-22 Thread Tom Lane
Andres Freund writes: > On 2023-02-22 16:38:51 -0500, Tom Lane wrote: >> The proposal so far was just to handle a function call wrapped >> around something else by converting to the function name followed >> by whatever we'd emit for the something else. > SELECT sum(relpages), sum(reltuples),

Re: Improving inferred query column names

2023-02-22 Thread Andres Freund
Hi, On 2023-02-22 16:38:51 -0500, Tom Lane wrote: > Vladimir Churyukin writes: > > It doesn't need to be perfect, but it needs to be consistent. So far you > > proposed a rule to replace () with _. What is the plan for expressions, how > > to convert them to names (with deduplication I guess?,

Re: Improving inferred query column names

2023-02-22 Thread Tom Lane
Vladimir Churyukin writes: > It doesn't need to be perfect, but it needs to be consistent. So far you > proposed a rule to replace () with _. What is the plan for expressions, how > to convert them to names (with deduplication I guess?, because there could > be 2 similar expressions mapped to the

Re: Improving inferred query column names

2023-02-22 Thread Vladimir Churyukin
On Wed, Feb 22, 2023, 12:40 PM Andres Freund wrote: > Hi, > > On 2023-02-11 12:47:04 -0800, Vladimir Churyukin wrote: > > That is a good idea for simple cases, I'm just curious how it would look > > like for more complex cases (you can have all kinds of expressions as > > parameters for

Re: Improving inferred query column names

2023-02-22 Thread Andres Freund
Hi, On 2023-02-11 12:47:04 -0800, Vladimir Churyukin wrote: > That is a good idea for simple cases, I'm just curious how it would look > like for more complex cases (you can have all kinds of expressions as > parameters for aggregate function calls). > If it works only for simple cases, I think

Re: Improving inferred query column names

2023-02-22 Thread Andres Freund
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 >

Re: Improving inferred query column names

2023-02-22 Thread Peter Eisentraut
On 20.02.23 16:17, David G. Johnston wrote: I think we should just do it and not care about what breaks.  There has never been any guarantee about these. I'm going to toss a -1 into the ring but if this does go through a strong request that it be disabled via a GUC.  The ugliness of

Re: Improving inferred query column names

2023-02-20 Thread David G. Johnston
On Mon, Feb 20, 2023 at 8:08 AM Peter Eisentraut < peter.eisentr...@enterprisedb.com> wrote: > On 11.02.23 20:24, Andres Freund wrote: > > > > I think on a green field it'd be clearly better to do something like the > > above. What does give me pause is that it seems quite likely to break > >

Re: Improving inferred query column names

2023-02-20 Thread Peter Eisentraut
On 11.02.23 20:24, Andres Freund wrote: Not useful column names: SELECT SUM(reads), SUM(writes) FROM pg_stat_io; column names: sum, sum So i often end up manually writing: SELECT SUM(reads) AS sum_reads, SUM(writes) AS sum_writes, ... FROM pg_stat_io; Of course we can't infer useful column

Re: Improving inferred query column names

2023-02-11 Thread Corey Huinker
On Sat, Feb 11, 2023 at 3:47 PM Vladimir Churyukin wrote: > For backwards compatibility I guess you can have a GUC flag controlling > that behavior that can be set into backwards compatibility mode if required. > The previous functionality can be declared deprecated and removed (with > the flag)

Re: Improving inferred query column names

2023-02-11 Thread Vladimir Churyukin
That is a good idea for simple cases, I'm just curious how it would look like for more complex cases (you can have all kinds of expressions as parameters for aggregate function calls). If it works only for simple cases, I think it would be confusing and not very helpful. Wouldn't it make more

Improving inferred query column names

2023-02-11 Thread Andres Freund
Hi, A common annoyance when writing ad-hoc analytics queries is column naming once aggregates are used. Useful column names: SELECT reads, writes FROM pg_stat_io; column names: reads, writes Not useful column names: SELECT SUM(reads), SUM(writes) FROM pg_stat_io; column names: sum, sum So i