通过.net数据适配器将0.001写入Postgres（9.1到9.3）会导致一个奇怪的0.00值（在pgAdmin中）显示为零，但不是。
实际上，像SELECT 1/(SELECT "weird_field" ...) FROM ...correcly这样的简单查询会给出1000。
更复杂的查询（带除法）意外地导致division by zero错误。
此外，在Navicat中按顺序排序正确地显示了介于0.0011和0.0009之间的值
我们使用Devart库连接到数据库，但罪魁祸首似乎是数据适配器（或者至少是这两者的组合），因为仍然通过Devart驱动程序的简单直接查询不会产生相同的结果。
知道怎么回事吗？
--
编辑：
数据库上的类型是numeric，在程序中表示为doubledecimal。
pSQL打印这个：
--
零
（1行）
--
编辑2：log_statement = 'all'给出了一个更奇怪的结果：
UPDATE "TABLE" SET ... "WEIRD_FIELD"=$8 ... WHERE ...
DETAIL: parameters: $1 = '7', $2 = '7', $3 = '18', $4 = '18', $5 = 'V03', $6 = 'Hz',
$7 = 'Hz', $8 = '0.00', $9 = '0', $10 = '2', $11 = '0'
怪异场的参数被打印为零（0.00），但显然它不是。。。
注意，DataAdapter填充的DataGridView中的值显示了正确的
0.001。--
编辑3（莫里斯）：
Devart适配器的问题似乎已修复。使用最新版本，我不再看到问题。我认为这与这个特定的修复有关：7.3.293 2014年11月20日：在使用PgSqlType时，会丢失精确性的错误
我使用最新的Devart程序集升级了我的软件，现在一切都按预期工作。
最佳答案
我们发现问题在于PgSql以未指定的精度和比例表示numerics（decimal）。
数据库中的值似乎是正确的（0.001），但在某些操作中它被截断：
"weird_field" + 0.001
---------------------
0.002
但是
"weird_field" * 2
--------------------
0.00
和
"weird_field" * 5
--------------------
0.01
这也解释了为什么有些查询会出现
division by zero错误。解决方案是指定精度和比例，例如我们选择了
numeric(38,28)（在Oracle中也用于decimal），所有这些都可以正常工作。--
查看PgSql文档，我们没有发现任何有关此行为的信息，因此我们认为这是一个错误：
指定：
数字
如果没有任何精度或小数位数，则创建一个列，在该列中可以存储任何精度和小数位数的数值，直至精度的实现限制。此类列不会将输入值强制转换为任何特定的比例，而具有声明的比例的数值列将输入值强制转换为该比例。
奇怪的是
0.000001（et similia）没有被截断，而0.001却被截断。关于.net - 通过数据适配器将0.001写入Postgres 9.x会产生一个奇怪的0.00值，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/27109361/