主要观点：设计数据库模式会引发诸多问题，选择对数据库性能、维护和扩展影响大，曾认为不使用 ENUMs，后发现其在 PostgreSQL 中支持已改善，应重新审视 ENUMs 的使用；介绍了 ENUMs 的实现方式（如在磁盘上占 4 字节、在pg_enum表中存储 OID 等）、生命周期（创建简单、可添加新值、重命名等）及使用 CHECK 约束作为替代的方法（可修改约束但会锁表、缺乏排序支持等）、参考表作为真正替代的方式（创建和使用示例、具有多种优势如自定义排序逻辑等），还讨论了性能考虑（ENUMs 性能较好、参考表需 JOIN 有开销），结论是应根据具体情况使用 ENUMs，且随着应用发展需重新考虑决策。

关键信息：

• PostgreSQL 9.1 引入可添加新值到 ENUMs 而无需重写表；10 版本增加重命名值；12 版本可在事务块中ALTER TYPE...ADD VALUE；PostgreSQL 17 允许在同一事务块中使用新添加的值。
• ENUMs 实现方式及pg_enum表结构相关细节。
• ENUMs 生命周期中的创建、添加新值、重命名等操作及限制。
• 使用 CHECK 约束替代 ENUMs 的方法、限制及示例。
• 参考表的创建、使用示例及优势（自定义排序、 deprecating 值、重命名、国际化、额外元数据等）。
• 性能考虑方面 ENUMs、CHECK 约束和参考表的特点。

重要细节：

• pg_enum表中enumlabel为 63 字节 varchar 用于存储系统标识符且大小写敏感。
• 更改 ENUMs 中现有值的唯一合适方式是创建新类型并更改列。
• 使用参考表设置默认值需特定操作。
• 未发布具体性能基准测试数据，但说明 ENUMs 性能较好、参考表因 JOIN 有开销且实际性能差异在实际应用中可能不显著。