Limitations on Partitioned Table Structure Adjustments

Note:
This topic has been translated from a Chinese forum by GPT and might contain errors.

Original topic: 分区表表结构调整限制

| username: porpoiselxj

In early versions of TiDB, operations that could potentially cause data loss, such as adjusting the precision of the decimal type or shortening the length of the varchar type, were not supported when modifying table structures. However, support for these operations on regular tables was added in version 6.1.1.

As of now, these features are still not supported for partitioned tables, which means that every time a partitioned table needs to be adjusted, the table has to be rebuilt, and data has to be imported and exported again, which is very cumbersome. It is unclear when support for partitioned tables will be added.

In the early days, such adjustments would result in a full table update, which was very confusing. Shouldn’t there be a check during table structure adjustments? If the operation would cause data loss, it should directly report an error and not support the modification. If the current data in the table meets the standards after downsizing, shouldn’t the table structure adjustment be completed quickly without actually updating the data?

| username: Jellybean | Original post link

First of all, it can be said that the official team is gradually improving various functional details.

At the same time, unexpected changes in field types in business operations are also non-anticipated phenomena. When creating tables, similar potential change requirements and scenarios should be considered; otherwise, the cost of conversion is usually quite high.

| username: WinterLiu | Original post link

Step by step, it will definitely become more refined in the future.

| username: WalterWj | Original post link

Everyone can reply and share whether you need this or not.

Your company’s product manager also wants to know the market demand for this.