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:
- Increasing NAMEDATALEN to 256 bytes or more
- Making NAMEDATALEN configurable at compile-time
- Changing NAMEDATALEN to represent character count instead of byte count
- Implementing a variable-length "name" data type
Challenges and Considerations
I'm aware that this change presents significant technical challenges:
- Maintaining backward compatibility
- Potential impacts on storage and performance
- 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.