最近，我将数据库迁移到PostgreSQL，其中有一些定义为numeric(9,3)和的列numeric(9,4)。在测试应用程序时，我发现当数据保存到这些列时，尾随零被添加到插入的值中。我正在使用Hibernate，并且我的日志显示为准备好的语句构建的正确值。
我要插入的数据示例是该列中的0.75，numeric(9,3)存储的值是0.750。该numeric(9,4)列的另一个示例：我插入值12，并且DB保持12.0000。
我发现了一个相关的问题：postgresql数字类型，不带尾随零。但是，除了引用9.x文档（未添加尾随零）之外，它没有提供其他解决方案。在这个问题上，答案引用了文档（我也阅读过），其中说：
数值物理存储，没有任何额外的前导或尾随零。因此，声明的列的精度和小数位数是最大值，而不是固定分配。
但是，就像问题海报一样，我看到添加了尾随零。Hibernate在日志中生成的原始插入内容不会显示此多余的行李。因此，我假设这是我未正确设置的PostgreSQL东西，只是找不到我怎么弄错了。
如果我在这种情况下正确理解“胁迫”，我想就是这样。这来自PostgreSQL文档：
可以配置数字列的最大精度和最大比例。要声明数值类型的列，请使用以下语法：
NUMERIC(precision, scale)精度必须为正，小数位数为零或正。或者：
NUMERIC(precision)选择0的小数位数。
NUMERIC不具有任何精度或小数位数的列会创建一列，其中可以存储任何精度和小数位数的数值，但不超过精度的实施限制。这种类型的列不会将输入值强制转换为任何特定的小数位数，而具有声明的小数位数的数字列将将输入值强制转换为该小数位。
大胆强调我的。
因此，稍后在同一部分中会产生误导：
数值物理存储，没有任何额外的前导或尾随零。因此，列的声明精度和小数位数是最大值，而不是固定分配。
再次大胆强调我的观点。
精度部分可能是这样，但是由于在定义比例时会强制将小数位，因此将尾随零添加到输入值中以满足小数位定义（如果太大，我会假定它会被截断）。
我正在使用精度，比例尺定义来实施约束。正是在DB插入期间，将尾随零添加到数字小数位数，这似乎支持强制转换，并且与不添加尾随零的语句产生冲突。
正确与否，做出选择后，我不得不在代码中处理问题。对我而言幸运的是，受影响的属性非常BigDecimal容易，因此剥离尾随零是很容易的（尽管不够优雅）。如果有人建议不要让PostgreSQL在插入时将尾随零添加到数字刻度上，那么我可以接受。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句