Re: NAMEDATALEN increase because of non-latin languages - Mailing list pgsql-hackers

From Ranier Vilela
Subject Re: NAMEDATALEN increase because of non-latin languages
Date
Msg-id CAEudQAqOqX0kZv=goGoXhC+LsutcBAXfsLyd_hDK=K_74a0A6A@mail.gmail.com
Whole thread Raw
In response to Re: NAMEDATALEN increase because of non-latin languages  (Laurenz Albe <laurenz.albe@cybertec.at>)
List pgsql-hackers
Em qua., 18 de ago. de 2021 às 09:33, Laurenz Albe <laurenz.albe@cybertec.at> escreveu:
On Wed, 2021-08-18 at 08:16 -0300, Ranier Vilela wrote:
> Em qua., 18 de ago. de 2021 às 08:08, Денис Романенко <deromanenko@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...
It seems to me that this is a case for macro:
HAS_SUPPORT_NAME_128_BYTES
Деnis Романенко would like and would pay the price for regression in exchange for the convenience.
What impacts him now is the difficulty of maintaining a private tree, with this support.

regards,
Ranier Vilela

pgsql-hackers by date:

Previous
From: Andy Fan
Date:
Subject: Re: Table AM modifications to accept column projection lists
Next
From: Mark Dilger
Date:
Subject: Re: Use extended statistics to estimate (Var op Var) clauses