alter column type 是唯一正解，postgresql 不支持 modify 或 change 语法，字段长度变更必须用 alter table ... alter column ... type，并在收缩时强制配合 using 子句处理视图依赖等问题。
ALTER COLUMN TYPE 是唯一正解，别试 MODIFY 或 CHANGE
PostgreSQL 不支持 MySQL 风格的 MODIFY 或 CHANGE 语法，所有字段长度变更必须走 ALTER TABLE ... ALTER COLUMN ... TYPE 路径。哪怕只是把 VARCHAR(50) 扩到 VARCHAR(100)，也得写全这个结构。
常见错误是照搬 MySQL 写法，比如：ALTER TABLE users MODIFY username VARCHAR(100); —— 这会直接报错 syntax error at or near "MODIFY"。
- 必须用
TYPE关键字，不能省略 - 目标类型要写完整，如
VARCHAR(200)、NUMERIC(12,2)，不能只写VARCHAR - 低版本（USING 子句；12+ 可省略，但显式写更稳妥
扩展长度前必查 MAX(LENGTH())，否则 ALTER 直接中断
执行 ALTER TABLE users ALTER COLUMN nickname TYPE VARCHAR(200); 时，PostgreSQL 会检查现有每条数据是否满足新长度。只要有一行实际字节长度超过 200，语句立刻失败，报错类似：ERROR: value too long for type character varying(200)。
这不是锁表问题，是硬性校验。所以扩长前务必先探底：
- 运行
SELECT MAX(LENGTH(nickname)) FROM users;—— 注意是LENGTH()，不是CHAR_LENGTH()（对多字节字符如中文结果一致，但LENGTH更通用） - 如果返回值是 198，那设
VARCHAR(200)安全；如果是 205，就得先清理或设更大值 - 对大表，加
WHERE条件限制范围再查，避免全表扫描拖慢
收缩长度必须先清理数据，USING 子句不可跳过
从 VARCHAR(100) 缩到 VARCHAR(50) 时，PostgreSQL 默认拒绝，除非你主动截断或删掉超长记录。直接执行 ALTER TABLE users ALTER COLUMN bio TYPE VARCHAR(50); 几乎必然失败。
安全做法分两步：
- 先清理：用
UPDATE users SET bio = LEFT(bio, 50) WHERE LENGTH(bio) > 50;或DELETE FROM users WHERE LENGTH(bio) > 50; - 再执行带
USING的转换：ALTER TABLE users ALTER COLUMN bio TYPE VARCHAR(50) USING bio::VARCHAR(50); -
USING在收缩场景不是可选——它明确定义了“怎么把旧值转成新类型”，缺了就报错
视图依赖时报错 cannot alter type，别急着改 pg_attribute
当 ALTER COLUMN TYPE 报错 cannot alter type of a column used by a view or rule，说明该字段被视图、物化视图或规则强引用。此时常规 DDL 被拦住，但直接更新 pg_attribute 是高危操作。
真正可落地的方案只有两个：
- 临时删重建视图：先
SELECT dependent_view.oid::regclass FROM pg_depend ...查出所有依赖视图，逐个DROP VIEW→ 执行ALTER→ 再CREATE VIEW。注意整个过程需在事务里，且视图定义复杂时容易漏逻辑 - 用
USING绕过类型校验（仅限扩展）：ALTER TABLE users ALTER COLUMN nickname TYPE VARCHAR(200) USING nickname;—— 这能避开依赖检查，但前提是新长度确实够用 - 直改
pg_attribute.atttypmod是最后手段：需超级用户、必须备份系统表、计算公式是新长度 + 4，错一位可能让后续查询返回截断值
字段长度变更看着简单，但实际卡点都在数据校验和依赖关系上。尤其大表收缩或视图环境，一个 USING 漏写或 MAX(LENGTH()) 没查，就会停在半路动不了。
