Re: Proposal to Compile a 256-Byte Identifier Length Version Alongside the Current 64-Byte Version

Laurenz Albe <laurenz(dot)albe(at)cybertec(dot)at> 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