Re: NAMEDATALEN increase because of non-latin languages

On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote:
> Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко <deromanenko(at)gmail(dot)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