Laurenz Albe <laurenz.albe@xxxxxxxxxxx> writes: > On Tue, 2023-10-10 at 15:53 +0900, Tatsuo Ishii wrote: >> Another solution would be, letting the meaning of NAMEDATALEN to be >> number of *characters*, not the number of bytes. This way, you can use >> up to 64 UTF-8 characters. In my understanding MySQL already does this >> way. I know this requires non trivial code modifications to PostgreSQL >> but would be better than to make binaries with random NAMEDATALEN >> values. > Since "name" is a fixed-length data type, that would require the stored > size to increase to accomodate the extra bytes. Wouldn't that change the > storage format and break pg_upgrade? Yeah, the real reason this is unlikely to happen is precisely that "name" is fixed-length. Increasing the standard NAMEDATALEN by 4x, or even 2x, has been proposed and rejected many times before because of the bloat it would cause in places like pg_attribute, pg_proc, in-memory tuple descriptors, etc. The real way forward IMO is to find a way to make "name" variable-length, thus both satisfying people who need a few long names and reducing overhead for everybody. This is difficult to do without breaking mountains of backend code, but there's been some discussions about ways to accomplish that. The most recent thread I could find is https://www.postgresql.org/message-id/flat/CALSd-crdmj9PGdvdioU%3Da5W7P%3DTgNmEB2QP9wiF6DTUbBuMXrQ%40mail.gmail.com regards, tom lane
