直接使用alter table 表名 alter column 字段名 type varchar(新长度) 不报错的前提是：表无视图/触发器依赖，且所有现有数据长度（字节）≤ 新长度；扩展时需先查max(length())确认，收缩前必须清理或截断超长数据，否则必报错。
ALTER COLUMN TYPE 语句怎么写才不报错
直接用 ALTER TABLE 表名 ALTER COLUMN 字段名 TYPE VARCHAR(新长度) 是最常用写法，但不是所有场景都适用。关键看 PostgreSQL 版本、字段当前类型、是否有视图/触发器依赖，以及是否收缩长度。
常见错误现象：ERROR: value too long for type character varying(50) —— 这说明表里已有数据超长，而你试图收缩或扩得不够；cannot alter type of a column used by a view or rule —— 表被视图强引用，DDL 被拦截。
- 扩展长度（如
VARCHAR(50) → VARCHAR(200)）：必须先查SELECT MAX(LENGTH(字段名)) FROM 表名;，确保结果 ≤ 新长度 - 收缩长度（如
VARCHAR(100) → VARCHAR(50)）：必须提前清理或截断超长数据，否则语句立刻失败 - 低版本（USING 字段名::VARCHAR(新长度)，否则报错；12+ 可省略，但加了更明确
- 跨类型修改（如
TEXT → VARCHAR(200)）：必须用USING substring(字段名 FROM 1 FOR 200)或USING left(字段名, 200)，否则类型转换失败
视图依赖时为什么 ALTER 失败，怎么绕过
PostgreSQL 把视图对字段的引用视为“强约束”，一旦字段被视图 SELECT 或 WHERE 引用，ALTER COLUMN TYPE 就会拒绝执行——这不是 bug，是设计使然。
推荐顺序是：先查依赖，再临时删重建视图。运行以下语句定位所有依赖视图：SELECT dependent_view.oid::regclass AS view_name FROM pg_depend JOIN pg_class AS dependent_view ON pg_depend.objid = dependent_view.oid WHERE pg_depend.refobjid = '表名'::regclass AND pg_depend.refobjsubid = (SELECT attnum FROM pg_attribute WHERE attrelid = '表名'::regclass AND attname = '字段名') AND dependent_view.relkind = 'v';
- 不要直接改
pg_attribute.atttypmod，除非你已在生产环境卡死且有完整备份，且确认自己是超级用户 - 改
atttypmod前必须执行SELECT * INTO pg_attribute_backup FROM pg_attribute;，误设会导致查询结果静默截断，极难排查 - 视图逻辑简单时，DROP + CREATE 是最稳妥路径；若视图含复杂 CTE 或嵌套，建议在事务块中操作：
BEGIN; DROP VIEW v1; ALTER TABLE ... ; CREATE VIEW v1 AS ...; COMMIT;
TEXT 转 VARCHAR 或收缩 VARCHAR 的实际坑点
TEXT 和 VARCHAR(N) 在存储层没有本质区别，但语义不同：前者无长度限制，后者带显式上限。转的时候最容易忽略的是隐式截断风险。
比如把 TEXT 字段改成 VARCHAR(100)，如果某条记录原文长 150 字符，又没指定 USING 行为，PostgreSQL 默认会报错，而不是自动裁剪。
- 安全做法分两步：先
UPDATE 表名 SET 字段名 = left(字段名, 100) WHERE length(字段名) > 100;，再ALTER TABLE 表名 ALTER COLUMN 字段名 TYPE VARCHAR(100); - 一步到位写法：
ALTER TABLE 表名 ALTER COLUMN 字段名 TYPE VARCHAR(100) USING substring(字段名 FROM 1 FOR 100);，但要注意substring对 null 和空字符串行为一致，而left在 null 上返回 null - 收缩
VARCHAR时，LENGTH()返回字节长度，不是字符数——如果字段存的是多字节 UTF-8 字符（如中文），LENGTH('你好') = 6，但只占 2 个字符。按字符截断要用CHAR_LENGTH()
大表改字段长度会不会锁表、耗多久
会锁表，而且锁的是整个表的写入（包括 INSERT/UPDATE/DELETE），读操作一般不受影响（除非开了 serializable 隔离级别）。耗时取决于表大小和硬件，但不是线性增长。
实测千万行表：扩 VARCHAR(10) → VARCHAR(100) 仅需约 2ms；但缩回 VARCHAR(99) 耗时超 12 秒——因为 PostgreSQL 必须逐行校验并重写数据页。
- 扩长度本身不重写数据，只更新元数据（
pg_attribute），所以快；缩长度或跨类型改必须重写整表，无法避免 - 业务高峰期严禁操作，尤其不能在 OLTP 核心表上直接跑
ALTER COLUMN TYPE - 真实大表（>500 万行）建议走分批迁移：新建带新结构的表 →
INSERT INTO 新表 SELECT ... FROM 旧表 LIMIT N OFFSET M→ 切流量 → 删旧表 - 别信“加索引不影响 ALTER”——如果字段上有索引，改完类型后索引仍可用，但若类型变更导致排序规则变化（如 collation 不同），索引可能失效
实际改字段最麻烦的从来不是语法，而是判断“有没有视图挡路”“数据到底多长”“下游系统会不会因截断出问题”。这些没法靠一条命令解决，得靠 SELECT MAX(LENGTH())、\d 表名、pg_depend 查询组合验证。
