Re: NAMEDATALEN increase because of non-latin languages
От | Julien Rouhaud |
---|---|
Тема | Re: NAMEDATALEN increase because of non-latin languages |
Дата | |
Msg-id | CAOBaU_bobU=3_FS-X2QrAJY2PLfgCWOp4fM5oZa4=-s+zWx2EQ@mail.gmail.com обсуждение исходный текст |
Ответ на | NAMEDATALEN increase because of non-latin languages (Денис Романенко <deromanenko@gmail.com>) |
Ответы |
Re: NAMEDATALEN increase because of non-latin languages
|
Список | pgsql-hackers |
On Wed, Aug 18, 2021 at 7:08 PM Денис Романенко <deromanenko@gmail.com> wrote: > > Hello dear hackers. I understand the position of the developers community about NAMEDATALEN length - and, in fact, 63 bytesis more than enough - but only if we speak about latin languages. > > Postgresql has wonderful support for unicode in table and column names. And it looks like very good idea to create tablewith names on native language for databases across the world. But when I want to create, for example, table with name"Catalog_Контрагенты_КонтактнаяИнформация" (that stands in Russian for catalog of counteragent contacts) it will be auto-shrinkedto "Catalog_Контрагенты_КонтактнаяИнформ". And this is not a fictional problem - many words in Russian are justlonger than it's English counterparts and I have many examples like this. > > Although recompiling the source is not so hard, updating is hard. I know that is not free for disk space because of storingtable names and field names but, from my point of view, in 2021 year convenience is more important than disk space. Unfortunately, the problem isn't really the additional disk space it would require. The problem is the additional performance hit and memory overhead, as the catalog names are part of the internal syscache. I understand your frustration, but given those problems I don't think that postgres will increase the default NAMEDATALEN value any time soon, even though it's in contradiction with the SQL standard.
В списке pgsql-hackers по дате отправления: