PostgreSQL未提供CREATE DATABASE IF NOT EXISTS的设计逻辑探究

• 显式操作优先的设计理念
  PostgreSQL团队始终强调操作的显式性，认为IF NOT EXISTS这类“静默跳过”的语法会掩盖潜在的逻辑问题。比如用户误输入数据库名、或者依赖的数据库本应存在却因配置错误不存在时，使用该语法会跳过报错，导致后续业务逻辑异常难以定位。团队更倾向于让用户明确知晓操作结果，而非自动忽略冲突。

• 重量级操作的安全性考量
  创建数据库属于相对重量级的系统操作，通常是初始化阶段的一次性动作。PostgreSQL团队认为，这类操作不应该被轻易地“自动跳过”——如果脚本重复执行导致多次触发创建逻辑，静默跳过可能隐藏脚本设计缺陷，或者导致冗余数据库资源的产生。要求用户显式判断存在性再执行创建，能提升操作的安全性和可控性。

• 透明化操作流程的哲学
  PostgreSQL提供的替代方案（如查询pg_database系统表判断数据库是否存在）虽然步骤更繁琐，但完全透明，让用户清晰掌控每一步操作逻辑。这符合PostgreSQL“让用户理解底层运作”的设计哲学，避免用户依赖语法糖而忽略操作背后的系统行为。

• 对象层级的场景差异
  虽然PostgreSQL对表、索引等底层对象支持IF NOT EXISTS，但数据库作为更高层级的对象，其使用场景与底层对象有明显差异：底层对象可能需要在脚本中频繁动态创建，而数据库的创建通常是静态初始化操作。团队认为针对数据库添加该语法的实际需求有限，因此没有纳入支持范围。

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