Navicat 15 无法正确同步 PostgreSQL 的 geometry 字段，因其缺乏对 PostGIS 复合类型（含 SRID、维度等）的元数据解析能力，导致字段退化为 bytea、属性丢失或 WKB 校验失败；必须通过手动 SQL 显式声明 geometry 类型、启用 postgis 扩展并用 INSERT SELECT 同步数据。
navicat 15 无法直接同步含 geometry 字段的 postgresql 表 —— 不是配置问题，是工具对 wkb 二进制结构解析存在硬限制。
为什么 Navicat 的“结构同步”会跳过或损坏 geometry 字段
Navicat 在比对表结构时，会尝试读取字段的类型定义和默认值，但对 public.geometry 这类复合类型（依赖 PostGIS 的 typmod 和 SRID）缺乏完整元数据解析能力。常见表现包括：
- 同步后目标表中
geometry字段变成bytea或空类型 - 字段长度被截断为固定值（如 255），触发
WKB structure does not match expected size错误 - SRID、维度（2D/3D）、坐标系等关键属性完全丢失
- 即使结构同步成功，后续插入数据仍因 WKB 校验失败而报错
绕过限制：用 SQL 脚本手动重建带 geometry 的表结构
不要依赖 Navicat 的图形化同步，改用可复现、可控的 SQL 方式。核心是显式声明 geometry 类型参数：
- 先在源库执行
SELECT pg_get_serial_sequence('your_table', 'geom');确认序列是否存在（避免主键冲突） - 导出建表语句时，务必包含
USING SRID=4326和GEOMETRYCOLLECTION等具体约束（例如：geom geometry(Point, 4326)） - 目标库执行前，确认已运行
CREATE EXTENSION postgis;，否则geometry类型不可识别 - 若需同步索引，单独导出
CREATE INDEX ON your_table USING GIST (geom);—— Navicat 的索引同步常忽略GIST特性
数据同步必须用 INSERT ... SELECT，禁用 Navicat 粘贴界面
Navicat 的单元格粘贴功能会将 WKB 数据强制转为文本再解析，极易破坏二进制结构。实测只要字段含 geometry，粘贴必触发 WKB structure does not match。
- 正确做法：在 Navicat 的查询窗口中执行
INSERT INTO target_table SELECT * FROM source_table; - 若跨库同步，先用
pg_dump --table=your_table --inserts --no-owner导出为 INSERT 语句，再手动替换表名后执行 - 注意：
ST_AsText(geom)可用于调试，但同步时必须保持原始二进制 WKB，不能转 WKT
PostGIS 扩展和权限是同步成功的前提条件
即使结构和数据都正确，目标库缺少 PostGIS 支持也会让 geometry 字段退化为无效类型：
- 连接目标库后，先运行
SELECT PostGIS_Version();验证扩展是否启用 - 若未启用，用超级用户执行
CREATE EXTENSION postgis;（不是CREATE EXTENSION postgis_topology;） - 确保连接用户对
publicschema 有USAGE权限，否则geometry类型无法解析 - Navicat 中新建字段时，“对象类型”选
public.geometry是无效操作 —— 必须通过 SQL 显式创建
真正麻烦的不是语法，而是 Navicat 把 geometry 当普通字段处理的底层假设。所有图形化操作都要打问号，SQL 才是唯一可信路径。
