Andrey Lepikhov <a.lepikhov@postgrespro.ru> writes:
> On 6/27/22 06:38, Masahiko Sawada wrote:
>>>> Regarding the patch, I think we can merge makeUniqueTypeName() to
>>>> makeArrayTypeName() as there is no caller of makeUniqueTypeName() who
>>>> pass tryOriginal = true.
>>> I partially agree with you. But I have one reason to leave
>>> makeUniqueTypeName() separated:
>>> It may be used in other codes with auto generated types. For example, I
>>> think, the DefineRelation routine should choose composite type instead
>>> of using the same name as the table.
No, this is an absolutely horrid idea. The rule that "_foo" means "array
of foo" is quite well known to a lot of client code, and as long as they
don't use any type names approaching NAMEDATALEN, it's solid. So we must
not build backend code that uses "_foo"-like type names for any other
purpose than arrays.
I suspect in fact that the reason we ended up with this orphaned logic
is that somebody pointed out this problem somewhere along the development
of multiranges, whereupon makeMultirangeTypeName was changed to not
use the shared code --- but the breakup of makeArrayTypeName wasn't
undone altogether. It should have been, because it just tempts other
people to make the same wrong choice.
Pushed with re-merging of the code into makeArrayTypeName and some
work on the comments.
regards, tom lane