Postgres do not allow to create many tables with more than 63-symbols prefix - Mailing list pgsql-hackers

From Andrey Lepikhov
Subject Postgres do not allow to create many tables with more than 63-symbols prefix
Date
Msg-id b84cd82c-cc67-198a-8b1c-60f44e1259ad@postgrespro.ru
Whole thread Raw
Responses Re: Postgres do not allow to create many tables with more than 63-symbols prefix
Re: Postgres do not allow to create many tables with more than 63-symbols prefix
List pgsql-hackers
Moved from the pgsql-bugs mailing list [1].

On 6/23/22 07:03, Masahiko Sawada wrote:
 > Hi,
 >
 > On Sat, Jun 4, 2022 at 4:03 AM Andrey Lepikhov
 > <a.lepikhov@postgrespro.ru> wrote:
 >>
 >> According to subj you can try to create many tables (induced by the case
 >> of partitioned table) with long prefix - see 6727v.sql for reproduction.
 >> But now it's impossible because of logic of the makeUniqueTypeName()
 >> routine.
 >> You get the error:
 >> ERROR:  could not form array type name for type ...
 >>
 >> It is very corner case, of course. But solution is easy and short. So,
 >> why not to fix? - See the patch in attachment.
 >
 > While this seems to be a good improvement, I think it's not a bug.
 > Probably we cannot backpatch it as it will end up having type names
 > defined by different naming rules. I'd suggest discussing it on
 > -hackers.
Done.

 > 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.

 > Also looking at other ChooseXXXName()
 > functions, we don't care about integer overflow. Is it better to make
 > it consistent with them?
Done.

[1] 
https://www.postgresql.org/message-id/flat/121e286f-3796-c9d7-9eab-6fb8e0b9c701%40postgrespro.ru

-- 
Regards
Andrey Lepikhov
Postgres Professional
Attachment

pgsql-hackers by date:

Previous
From: Peter Smith
Date:
Subject: Re: Handle infinite recursion in logical replication setup
Next
From: Noah Misch
Date:
Subject: Re: Postgres perl module namespace