navicat 模型设计器不支持 postgresql 数组类型，解析时丢弃“[]”后缀，导致 erd 和 ddl 丢失维度信息；唯一可靠方案是全程使用 sql 管理数组字段，并手动修正同步脚本。
Navicat 的模型设计器根本不识别 PostgreSQL 数组类型
Navicat for PostgreSQL（包括 17 版）的「模型」功能（即实体关系图 ERD）在解析和生成 PostgreSQL 数组字段时，会直接丢弃 [] 后缀。你手动在表设计界面输入 text[] 或 integer[]，保存后模型里显示的仍是 text、integer —— 不是 UI 刷新问题，是模型层压根没把数组当作独立类型建模。
这不是配置能打开的功能，而是 Navicat 模型引擎对 PostgreSQL 元数据（pg_attribute.attndims、pg_type.typarray）的忽略所致。它只读 format_type(atttypid, atttypmod) 的主类型名，不解析维度信息。
所以：如果你依赖模型自动生成 DDL、做正向/反向工程、或导出逻辑视图，数组字段一定会丢失维度声明，后续同步或迁移必然失败。
绕过模型，用 SQL 建模 + 手动维护数组字段
想让数组字段在 Navicat 中“存在且可用”，唯一可靠路径是跳过图形化模型，改用纯 SQL 方式定义和管理：
- 新建查询窗口，手写
CREATE TABLE，明确写出tags text[]、roles varchar(50)[]等带[]的列定义 - 执行后，在「对象浏览器」中右键该表 → 「设计表」→ 进入字段列表，你会发现数组列已存在，类型显示为
text[]（注意：此时不是模型视图，是真实表结构反射） - 后续修改（如
ALTER TABLE ADD COLUMN scores numeric[]）也必须走 SQL，不能依赖模型编辑器的“添加字段”按钮 - 若需导出结构，用
pg_dump -s -t table_name db_name，别信模型导出的 SQL
同步或迁移含数组字段的表时，必须拦截并重写 Navicat 生成的脚本
Navicat 的「结构同步」或「数据传输」功能在对比源/目标表时，只要遇到数组字段，就会在生成的 DDL 中犯两类错误：
-
ADD COLUMN tags ARRAY：缺元素类型，PostgreSQL 拒绝执行 -
ADD COLUMN tags text：漏掉[]，导致后续插入报ERROR: column "tags" is of type text but expression is of type text[]
因此，每次点击「下一步」后，务必点开「查看脚本」，人工扫描所有 ADD COLUMN 和 ALTER COLUMN TYPE 语句：
- 把
text改成text[]，varchar(100)改成varchar(100)[] - 把孤立的
ARRAY替换为完整形式，例如tags text[] USING tags::text[] - 特别注意
USING子句：类型变更必须显式强制转换，否则报错
复杂数组操作（如多维、嵌套、自定义类型数组）请彻底放弃 Navicat 模型
Navicat 对 int[][]、jsonb[]、甚至 my_composite_type[] 这类结构完全无支持。它连一维 text[] 都解析不全，更别说维度 >1 或元素类型非基础类型的场景。
这类需求必须回归原生工具链：
- 用
psql直接执行\d+ table_name确认真实结构 - 用
pg_dump --inserts -t table_name db_name导出带数组值的 INSERT 语句（注意{}语法是否被正确转义） - 写脚本校验数组字段长度、维度、元素类型，别指望 Navicat 的「数据编辑器」能正确渲染或编辑多维数组内容
模型只是草图，PostgreSQL 的数组语义在 Navicat 里没有对应物——接受这点，才能避免反复踩坑。
