Navicat 17 导入数据时无法识别 PostgreSQL 自定义枚举类型，因其导入向导不查询 pg_type 元数据，仅依赖 JDBC 的 OTHER 映射，导致下拉列表中不显示 user_status 等枚举；需改用 INSERT...SELECT 强制转换、psql COPY 或手动 SQL 导入。
Navicat 17 导入数据时找不到 PostgreSQL 自定义枚举类型
因为 navicat 在「数据导入」流程中不解析或加载数据库已有的自定义类型（包括 create type ... as enum 定义的枚举），它只识别内置基础类型（如 text、integer、date）和极少数预注册的系统枚举（如 pg_catalog.pg_loglevel）。导入向导的类型下拉菜单里不会出现你用 create type user_status as enum ('active', 'inactive') 创建的 user_status。
导入时选不到枚举类型，但表结构里明明有
这是设计限制，不是 bug。Navicat 的导入功能面向“快速填充”，默认绕过类型元数据查询，直接依赖 PostgreSQL JDBC 驱动返回的 getJDBCType() 映射——而该映射对用户自定义枚举一律返回 OTHER，不暴露具体类型名。
- 你在「表设计器」里能正常看到字段类型是
user_status，是因为设计器主动执行了SELECT typname FROM pg_type WHERE typtype = 'e' - 但导入向导跳过了这一步，它只查
INFORMATION_SCHEMA.COLUMNS，而该视图对自定义枚举的data_type字段固定返回USER-DEFINED，不提供真实类型名 - 结果就是：向导里下拉列表空着，或只显示
text/varchar等兜底选项
绕过限制的三种实操路径
必须跳出「用向导直接导入」这个思维定式：
-
路径一（推荐）：先用 Navicat 执行
INSERT INTO ... SELECT ...，把源数据读进一张临时text表，再用INSERT INTO target_table (status) SELECT status::user_status FROM temp_table强制转换——PostgreSQL 服务端会校验并转成合法枚举值 -
路径二：改用
psql命令行 +COPY，它原生支持枚举类型：COPY users(status) FROM '/path/data.csv' WITH (FORMAT csv, HEADER true)，前提是 CSV 中 status 列值严格匹配枚举定义（如active，不能多空格） -
路径三：在 Navicat 查询窗口手动写
INSERT或调用pg_read_file()读取文件后处理，适合小批量且需清洗的场景
为什么 MySQL 的 ENUM 在 Navicat 导入里反而“看得见”？
因为 MySQL 的 ENUM 是内建类型，不是用户创建的独立对象。Navicat 对 MySQL 连接做了特殊适配：当检测到列类型为 enum 时，会自动从 SHOW COLUMNS 结果中提取 Type 字段里的括号内容（如 enum('a','b')），并用于导入映射。但 PostgreSQL 没这套逻辑——它的枚举是独立对象，依赖 pg_type 元数据，而导入模块根本没去查。
真正麻烦的是，一旦你误选 text 类型导入，数据会以字符串形式存进字段，后续查询时看似正常，但实际已丢失类型约束；等哪天想加 CHECK 或排序，才发现值不是真正的枚举成员。
