Navicat逆向工程根本读不到PostgreSQL分区表元数据，因其硬编码SQL仅查询pg_class中relkind='r'的普通表，直接过滤relkind='p'（分区表）和'I'（分区索引），导致主表、子表、分区键、继承关系及约束均无法识别，必须改用pgAdmin、DBEAVER或命令行。
Navicat 逆向工程根本读不到分区表元数据
Navicat 不是“识别不准”，而是压根不查。它所有逆向逻辑都基于一条硬编码 SQL：SELECT c.oid, c.relname, n.nspname FROM pg_class c JOIN pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind = 'r'。这条语句把 relkind = 'p'（分区表）、relkind = 'I'（分区索引）全部过滤掉，所以主表和子表都不会进入模型。你看到的“主表存在”，大概率是手动建的空壳，不是从数据库拉出来的。
分区键、继承关系、子表约束全被跳过
即使你连的是 PostgreSQL 15，Navicat 也不会去查 pg_partitioned_table、pg_inherits 或 pg_constraint 这些关键系统表。结果就是：
-
PARTITION BY RANGE (ts)这类定义不会变成模型里的任何属性 - 子表如
logs_2024_q1不会出现在对象列表中，更不会自动建立继承连线 - 主表上的
CHECK约束不会被继承到子表，但 Navicat 模型里连“主表有 CHECK”都识别不出来 - 导出 DDL 时，
CREATE TABLE ... PARTITION OF ...语句必然缺失，只剩一个无分区逻辑的空表
ER 图里无法表达“继承约束”这一语义
PostgreSQL 分区表的核心语义是：子表自动继承主表的约束（除 PRIMARY KEY 外），但 Navicat 模型根本不支持这种关系建模。你手动拖一个子表进模型，它就是一个孤立表——外键、索引、CHECK、DEFAULT 都得单独重写一遍，否则同步或导出时就丢。最常被忽略的一点是：NOT NULL 和 DEFAULT 在子表上不是继承来的，而是必须显式定义；Navicat 不会帮你补，也不会报错提醒。
别等修复，换工具或改用命令行验证
Navicat 官方没把分区表支持排进开发计划。实测能真正识别的替代路径只有三个：
-
pgAdmin 4/5：对象浏览器里有独立的 “Partitioned Tables” 节点，右键 → Properties 就能看到完整分区树和每个子表的FOR VALUES -
DBEAVER（启用 PostgreSQL 插件后）：“Tables” 下展开有 “Partitions” 子节点，双击可直查pg_partitioned_table原始数据 - 命令行才是唯一可信源：
SELECT pt.*, c.relname FROM pg_partitioned_table pt JOIN pg_class c ON c.oid = pt.partrelid;—— 这个结果不依赖任何 GUI 解析逻辑，最准
