PostgreSQL 11中更新pg_catalog.pg_attribute是否可行？更新仅对新数据生效吗？

直接更新pg_catalog.pg_attribute是否合理？ #

绝对不推荐直接修改系统目录表，理由如下：

• 破坏元数据一致性：PostgreSQL的系统目录是核心元数据存储，直接更新绕过了官方的元数据管理逻辑，会导致内存缓存（共享缓存、会话缓存）与磁盘上的元数据不一致，引发查询计划错误、约束校验失效等隐性问题。
• 无数据校验：比如你执行的UPDATE pg_catalog.pg_attribute语句设置attnotnull = TRUE，但不会检查表中已有数据是否存在NULL值，直接留下数据与元数据不匹配的矛盾状态。
• 无官方支持：这类操作属于未被PostgreSQL官方认可的非标准操作，一旦出现数据库崩溃、数据损坏等问题，官方不会提供技术支持。
• 正确替代方案：使用标准的ALTER TABLE语句完成约束修改，它会自动处理所有必要的一致性检查和缓存同步：

  ALTER TABLE tttt2 ALTER COLUMN b SET NOT NULL;
  

  这条语句会先检查表中已有数据是否符合非空约束，通过后再更新元数据、同步缓存，并记录合法的事务日志，全程保证数据一致性。

此类目录更新仅对新增数据生效的情况是否普遍？ #

是的，这种情况在绝大多数场景下成立：

• 缓存未同步：数据库的共享缓存和会话缓存中已经加载了旧的元数据，直接修改磁盘上的系统目录后，这些缓存不会自动刷新，当前及已连接的会话会继续使用旧规则处理已有数据。
• 无数据修正逻辑：直接修改元数据不会触发对已有数据的校验或转换，比如你设置attnotnull = TRUE后，表中已有的NULL值依然存在，只有新增数据时，数据库才会读取新的元数据进行约束校验。
• 不可控的例外场景：如果手动刷新缓存（如执行SELECT pg_stat_clear_snapshot();）或重启数据库，后续对已有数据的某些操作（如全表扫描）可能会触发新的约束检查，但这属于数据库内部执行逻辑的偶然行为，完全不可控，不能依赖它来保证数据合规。

内容的提问来源于stack exchange，提问作者satya prakash