On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote: > Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко <deromane...@gmail.com> > escreveu: > > Hello dear hackers. I understand the position of the developers community > > about > > NAMEDATALEN length - and, in fact, 63 bytes is 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 table with 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-shrinked to > > "Catalog_Контрагенты_КонтактнаяИнформ". And this is not a fictional > > problem - > > many words in Russian are just longer 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 storing table names and field names > > but, > > from my point of view, in 2021 year convenience is more important than > > disk space. > > > > I ask you to consider increasing NAMEDATALEN for maybe 128 bytes in future > > releases.
My stance here is that you should always use ASCII only for database identifiers, not only because of this, but also to avoid unpleasant encoding problems if you want to do something like pg_dump -t Catalog_Контрагенты_КонтактнаяИнформация mydb on a shell with an encoding different from the database encoding. So I am not too excited about this. > +1 once that Oracle Database 12.2 and higher, has support for 128 bytes names. > What possibly, in the future, could impact some migration from Oracle to > Postgres. That seems to be a better argument from my point of view. I have no idea as to how bad the additional memory impact for the catalog caches would be... Yours, Laurenz Albe
