CEIL与CEILING在PostgreSQL中完全等价，均向上取整（向正无穷），但需警惕浮点精度导致的取整错误及负数行为是否符合业务逻辑。
CEIL 和 CEILING 在 PostgreSQL 中完全等价，都执行向上取整（向正无穷方向），库存计算中用它们没问题，但必须注意输入类型和小数精度陷阱。
CEIL 与 CEILING 真的不一样吗？
完全一样。PostgreSQL 把 CEILING 当作 CEIL 的同义词，源码里直接 alias 过。调用 CEILING(2.1) 和 CEIL(2.1) 返回结果、执行计划、性能毫无区别。没必要纠结选哪个——团队统一用 CEIL 更常见，文档和老代码里出现频率更高。
库存场景下最常踩的坑：浮点数精度导致向上取整失效
比如要按“每箱装 6 件”计算最少需要几箱，写成 CEIL(quantity / 6.0) 看似合理，但若 quantity 是 DOUBLE PRECISION 或来自浮点运算（如除法中间结果），可能产生类似 5.000000000000001 这种值，CEIL 会错误返回 6 而非预期的 5。
- 用
NUMERIC类型替代浮点类型存储原始库存量（如quantity NUMERIC(10,2)） - 强制转换：把除法转为
NUMERIC再取整，例如CEIL((quantity::NUMERIC) / 6.0) - 如果源头是浮点计算，先用
ROUND(x, 6)截断尾差再进CEIL
CEIL 处理负数时的行为必须确认是否符合业务逻辑
库存一般不会是负数，但若上游数据异常或做预测模拟，CEIL(-2.7) 返回 -2（不是 -3）。也就是说，它“向上”是指数学上的“向正无穷”，不是“向绝对值更大方向”。这在缺货预警、负向调拨等边缘场景容易出错。
- 检查业务规则：-2.7 件是否真该算作“还需补 2 件”，还是该按 -3 件处理
- 若需向零截断后向上取整（即负数也朝更缺的方向进位），改用
CASE WHEN x - 别依赖直觉，对负输入加单元测试，例如验证
CEIL(-0.1)→0是否可接受
真正麻烦的从来不是函数怎么写，而是你不知道 quantity 字段背后是不是某个视图里嵌套了三次 CAST，或者前端传来的 JSON 数字在 pgjdbc 里悄悄变成了 double。查清楚数据链路里的类型流转，比记住 CEIL 语法重要得多。
