Navicat 中直接执行 ALTER TABLE 在标准 PostgreSQL 上是安全的，因 PostgreSQL 保证 DDL 原子性，但部分操作会锁表或触发全表重写；可视化设计表功能不支持分区、生成列、行级安全等高级特性，且生成 SQL 常遗漏 IF EXISTS，分区操作必须手写 SQL。
ALTER TABLE 语法在 Navicat 中直接执行是否安全
只要 navicat 连接的是标准 postgresql 实例（非只读副本、无 ddl 锁限制），alter table 命令本身是安全的——postgresql 保证 ddl 原子性，失败即回滚。但「安全」不等于「无感知」：某些操作会锁表（如添加 not null 列且无默认值）、阻塞写入，甚至触发全表重写（如修改列类型导致数据转换）。
实操建议：
- 先在测试库运行
EXPLAIN (VERBOSE, ANALYZE)检查是否涉及REWRITE，尤其对大表要警惕 - 避免在业务高峰执行
ALTER TABLE ... TYPE或ADD COLUMN ... NOT NULL - Navicat 的可视化「设计表」界面底层仍生成
ALTER TABLE，但它不会提示锁影响，别盲目点「保存」
Navicat 可视化修改不支持的 PostgreSQL 高级特性
Navicat 表设计器能覆盖基础字段增删改、索引、主键，但对 PostgreSQL 特有功能基本无图形入口，比如生成列（GENERATED ALWAYS AS）、分区绑定（ATTACH PARTITION）、行级安全策略（CREATE POLICY）等，必须手写 SQL。
常见错误现象：
- 试图用界面给 JSONB 字段加 GIN 索引，发现下拉菜单里只有 B-tree 和 Hash
- 想设一个表达式索引（如
CREATE INDEX ON users ((lower(email)))），界面里找不到「表达式」输入框 - 修改字段类型为
ENUM或RANGE，界面报错或静默忽略
此时必须切到 Navicat 的「查询」窗口，手动执行对应 ALTER TABLE 或 CREATE INDEX 语句。
修改列默认值或约束时，Navicat 自动生成的 SQL 容易漏掉 IF EXISTS
Navicat 在「设计表」中删除默认值或唯一约束时，生成的 SQL 类似 ALTER TABLE t DROP CONSTRAINT uk_name。如果该约束名在不同环境不一致（比如开发环境叫 uk_email，生产环境是 t_email_key），直接执行会报错：ERROR: constraint "uk_name" of relation "t" does not exist。
实操建议：
- 导出变更前，手动把生成的 SQL 改成
ALTER TABLE t DROP CONSTRAINT IF EXISTS uk_name - 查看现有约束名用
\d t（psql）或查pg_constraint视图，别依赖 Navicat 界面显示的名字 - 对部署脚本，优先用
pg_dump --schema-only对比结构差异，而非依赖 Navicat 导出
分区表结构调整必须绕过 Navicat 界面
Navicat 的表设计器对分区表（PARTITION BY RANGE/LIST/HASH）完全失效：它无法识别父表与子表关系，点开「设计」可能只显示父表空结构，或报错「relation does not exist」。任何分区相关操作都得走 SQL。
典型场景：
- 给已存在的分区表新增分区：必须手写
CREATE TABLE ... PARTITION OF ... FOR VALUES ... - 拆分现有分区：需先创建新分区，再用
INSERT INTO ... SELECT搬数据，最后DELETE原分区数据（不能用TRUNCATE） - 修改分区键表达式：PostgreSQL 不支持直接改，得重建整个分区结构
分区键一旦定下就很难动，Navicat 不提供任何辅助，连语法高亮和补全都靠不住，写错一个括号就卡住。
复杂点在于：分区操作常伴随长事务和锁升级，而 Navicat 默认事务超时短，容易中断；更麻烦的是，它不显示后台进程（pg_stat_activity），你根本不知道那个 ALTER TABLE 是卡在 IO 还是等锁。
