Navicat结构对比卡在“正在获取表元信息”是因为目标库用户缺少SELECT ON pg_locks权限，导致线程静默挂起；需superuser执行GRANT SELECT ON pg_locks TO your_user，并补充information_schema.tables和pg_views查询权限。
navicat 能对比 postgresql 数据库结构，但必须满足连接状态、权限和对象命名三重前提，否则大概率显示空白或卡在“正在获取表元信息”。
为什么点“结构对比”后一直卡在“正在获取表元信息”？
这是 PostgreSQL 用户最常遇到的阻塞点，根本原因不是网络慢，而是目标库连接用户缺 LOCK TABLES 权限（即使 Navicat 界面没报错）。
- PostgreSQL 实际不叫
LOCK TABLES，但 Navicat 会尝试执行SELECT pg_locks.* FROM pg_locks类语句来探测锁状态；若用户无pg_locks视图查询权限，线程就静默挂起 - 确认方式：用该用户登录 psql，执行
SELECT 1 FROM pg_locks LIMIT 1;，报错即缺权限 - 修复命令（需 superuser 执行）：
GRANT SELECT ON pg_locks TO your_user; - 另两个关键权限不能少：
SELECT ON information_schema.tables和SELECT ON pg_views（视图比对依赖后者）
PostgreSQL 表结构比对时，哪些差异是“假阳性”？
Navicat 对 PostgreSQL 的 DDL 解析不如 MySQL 稳定，容易把语义一致的写法判为不同。
-
serialvsinteger GENERATED BY DEFAULT AS IDENTITY：两者功能等价，但 Navicat 默认视为类型不一致；建议在 Compare Options 中勾选Ignore data type differences - 注释差异：PostgreSQL 注释存在
pg_description系统表，但 Navicat 的Ignore comments开关对它有效；若仍报差异，检查是否源库用了COMMENT ON COLUMN而目标库漏执行 - 索引定义顺序：Navicat 把
CREATE INDEX idx ON t(a,b)和CREATE INDEX idx ON t(b,a)当成不同，但实际是两个独立索引——这不是误报，是真实差异，需人工确认业务逻辑
如何安全比对两个 PostgreSQL 数据库里的视图？
Navicat 的结构同步不支持跨库视图 DDL 自动比对，必须手动导出再 diff。
- 右键源库 →
备份数据库→ 勾选“仅导出结构”+“包含删除语句”+“导出为 SQL 文件” → 选中要对比的视图 - 对目标库重复相同操作，得到两个 SQL 文件
- 用文本比较工具（如 VS Code 内置 diff）打开，聚焦比对
AS SELECT后面的实际查询部分；忽略CREATE OR REPLACE VIEW前缀、owner、search_path 等环境相关字段 - 特别注意：PostgreSQL 视图若引用了函数或自定义类型，需先确认这些依赖对象在两边库中定义完全一致，否则 DDL 语义已不同
生成同步 SQL 前必须改掉的三个 PostgreSQL 特有陷阱
Navicat 生成的 PostgreSQL 同步脚本默认不兼容生产环境，直接执行可能失败或破坏数据。
- 默认含
SET CONSTRAINTS ALL DEFERRED：该语句在事务中延迟约束检查，但若目标库已有脏数据，会导致后续ALTER TABLE报错；建议删掉这行，改用SET CONSTRAINTS ALL IMMEDIATE - 对
ENUM类型新增值，Navicat 生成ALTER TYPE ... ADD VALUE，但 PostgreSQL 10+ 要求该操作必须在事务外执行；需手动拆出该语句，单独执行 - 导出的 SQL 文件末尾无分号，PostgreSQL 执行时报
ERROR: syntax error at end of input；必须全局替换\n为;\n，或在导出前勾选“每条语句后添加分号”（藏在“高级”选项页）
PostgreSQL 的元数据存储机制和权限模型比 MySQL 更细粒度，Navicat 的抽象层容易漏掉底层细节。真正可靠的比对，永远始于 psql 里亲手验证 information_schema 和 pg_catalog 查询结果是否可读、是否完整。
