Re: Proposition for autoname columns - Mailing list pgsql-hackers

From Eugen Konkov
Subject Re: Proposition for autoname columns
Date
Msg-id 836168461.20201112221308@yandex.ru
Whole thread Raw
In response to Re: Proposition for autoname columns  (Alvaro Herrera <alvherre@alvh.no-ip.org>)
List pgsql-hackers
> On 2020-Nov-12, Tom Lane wrote:

>> On the whole, I'm on the side of the people who don't want to change this.
>> The implementation cost seems likely to greatly outweigh the value, plus
>> it feels more like a wart than a feature.

> I think if Eugen wants to spend some time with it and see how it could
> be implemented, then sent a patch for consideration, then we could make
> a better informed decision.  My own opinion is that it's not worth the
> trouble, but I'd rather us not stand in his way if he wants to try
> (With disclaimer that we might end up not liking the patch, of course).

Sorry, I am not C/C++ programmist and do not imagine how to start to patch.
I do not know internals of PG. The only useful thing from me is just that idea
to make world better.

I suppose initially there were only ?column?, later names were implemented for count, sum etc
But it will be cool if PG will do step further and name sum( a ) as  sum_a instead of just sum

The purpose of this proposition is not about correct name generation, the purpose to get
more distinct default names:
?column?, ?column?, ?column?, ?column?, ?column?, ?column?, ?column?,

?count?, ?count?, ?count?, ?sum?, ?sum?, ?sum?, ?sum?

?count_a?, ?count_b?, ?count_c?, ?sum_a?, ?sum_b?, ?sum_c?, ?sum_d?

Notice, that latest is more robust that first ;-)

I  suppose  we  just  ignore  comlex  cases  and left them as they are
current.  We  could  try some very very small step at the direction to
improve  default  names  and  see  feed back from many users how it is
useful  or  not. Then we can decide it worth or not to implement whole
system for default name generation.

Unfortunately I am not judje at which level those should occur: parser, analiser or so.
I just does not understand those things =(

Thank you.

--
Best regards,
Eugen Konkov




pgsql-hackers by date:

Previous
From: e.sokolova@postgrespro.ru
Date:
Subject: Re: [PATCH] Add extra statistics to explain for Nested Loop
Next
From: Tom Lane
Date:
Subject: Re: avoid bitmapOR-ing indexes with scan condition inconsistent with partition constraint