Feature Request: Extending PostgreSQL's Identifier Length Limit

*The Current Situation*
As a long-time PostgreSQL user, I've increasingly run into issues with the
63-byte limit for identifiers, particularly table names. This limit, while
historically sufficient, is becoming a significant pain point in modern
database design and usage.

*Real-World Examples*
The problem is particularly evident in English table names, which make up a
large portion of PostgreSQL's user base:

- "Gross Domestic Product, Billions of Dollars, Not Seasonally Adjusted
(GDPA)~Percent Change from Year Ago"
- "Inflation, consumer prices for the United States, Percent, Not
Seasonally Adjusted (FPCPITOTLZGUSA)"
- "Annual Average Consumer Price Index for All Urban Consumers (CPI-U):
U.S. City Average, All Items"

These names, while descriptive and useful, exceed our current limit. The
issue extends to multi-byte character sets as well, such as this Chinese
table name:

- "能源消耗统计_全球主要国家石油与天然气使用量_年度碳排放与可再生能源比例表" (Energy consumption statistics
table)

*Why This Matters*
In my experience, the complexity of data and the need for self-documenting
schemas have grown significantly. We're dealing with:

- Increasingly descriptive table names for clarity and self-documentation
- Automated systems generating tables with detailed, often lengthy names
- A growing international user base requiring support for multi-byte
characters

While workarounds exist, such as using abbreviations or moving descriptions
to comments, these solutions often lead to less intuitive database designs
and reduced readability.

*Potential Solutions*
Based on community discussions, I believe we should consider:

1. Increasing NAMEDATALEN to 256 bytes or more
2. Making NAMEDATALEN configurable at compile-time
3. Changing NAMEDATALEN to represent character count instead of byte
count
4. Implementing a variable-length "name" data type

*Challenges and Considerations*
I'm aware that this change presents significant technical challenges:

1. Maintaining backward compatibility
2. Potential impacts on storage and performance
3. Complexities in implementation, especially if moving to a
variable-length system

Despite these challenges, I believe addressing this limitation is crucial
for maintaining PostgreSQL's position as a versatile, user-friendly
database system.

*Call to Action*
I respectfully request the PostgreSQL development team to consider this
feature request. While I understand the technical complexities involved, I
believe the benefits to the user experience would be substantial.
I'm eager to contribute to discussions and potentially assist in testing
any proposed solutions. Let's work together to enhance PostgreSQL's
capability to handle the evolving needs of modern database users.
Thank you for your consideration and your ongoing efforts in improving
PostgreSQL.