从Oracle Enterprise迁移至PostgreSQL：NUMBER类型适配问题咨询

为什么 orafce 没有实现 Oracle NUMBER 类型？ #

Oracle的NUMBER是支持可变精度的任意精度数值类型，而PostgreSQL原生的numeric（对应SQL标准的DECIMAL）已经完全覆盖了它的功能——当不指定精度和刻度时，numeric最多支持131072位数字，远超Oracle NUMBER的限制。

orafce的定位是补充Oracle特有的、PostgreSQL原生没有的类型或行为（比如Oracle DATE包含时分秒而PostgreSQL原生DATE只存日期，VARCHAR2的字符长度语义差异），而NUMBER的核心功能PostgreSQL原生就已经满足，因此没必要重复实现。

用 CREATE DOMAIN NUMBER AS BIGINT 的可靠性分析 #

这个方案仅适用于极端特定场景，整体可靠性极低，主要问题包括：

• 范围限制：BIGINT的取值范围是-9223372036854775808到9223372036854775807，Oracle NUMBER可以存储远超出这个范围的数值，一旦业务数据超出，会直接触发插入/查询错误，导致数据丢失或业务中断。
• 小数丢失：Oracle NUMBER支持存储小数，而BIGINT是纯整数类型，若原系统中存在隐式存储小数的情况（比如用NUMBER存123.45），迁移后会直接截断小数部分，造成数据不一致。
• 扩展性差：即使当前数据都在BIGINT范围内，未来业务扩展可能产生超出范围的数值，埋下隐性故障隐患。

只有当你能100%确认所有NUMBER列仅存储BIGINT范围内的整数时，这个方案才勉强可用，但依然不推荐。

推荐的迁移方案 #

• 首选：直接映射为PostgreSQL numeric类型
  这是最安全、最通用的方案，完全匹配Oracle NUMBER的任意精度特性，不需要依赖任何扩展，PostgreSQL对numeric的性能优化也能应对绝大多数业务场景。
• 兼容Oracle语法的方案：创建DOMAIN映射到numeric
  如果需要保留代码中的NUMBER类型名称，可以执行以下语句：

  CREATE DOMAIN NUMBER AS numeric;
  

  这样既兼容了原有的类型写法，又保留了numeric的全部功能，避免了BIGINT的局限性。
• 特定场景优化：明确为BIGINT
  对于经过全面数据校验，确认仅存储BIGINT范围内整数的列，可以显式改为BIGINT类型，以此获得更好的性能，但必须提前做好数据范围和类型的校验工作。

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