3

我在 PostgreSQL 表中有一个小数字：

test=# CREATE TABLE test (r real);
CREATE TABLE
test=# INSERT INTO test VALUES (0.00000000000000000000000000000000000000000009);
INSERT 0 1

当我运行以下查询时，它返回的数字为8.96831e-44：

test=# SELECT * FROM test;
      r      
-------------
 8.96831e-44
(1 row)

如何psql以十进制形式 ( 0.00000000000000000000000000000000000000000009) 而不是科学记数法显示值？我也会很高兴的0.0000000000000000000000000000000000000000000896831。不幸的是，我无法更改表格，而且我并不真正关心精度损失。

（我玩了to_char一段时间没有成功。）

4

1 回答 1

2

Postgres 中的实数是浮点数据类型，存储在 4 个字节上，即 32 位。

你的价值，

0.00000000000000000000000000000000000000000009

不能用 32 位 IEEE754 浮点数精确表示。您可以在此计算器中检查确切的值

根据计算器，您冷尝试并使用双精度（64 位）来存储它，这似乎是一个精确的表示。 不正确Patricia 表明它只是计算器对值进行四舍五入，即使明确要求它不要... Double 意味着更高的精度，但仍然没有确切的值，因为这个数字无法使用有限数量的二进制数字表示. （谢谢，Patricia，（再次）吸取的教训：不要相信你在 Intertubez 上看到的东西）

在正常情况下，您应该使用 NUMERIC(precision, scale) 格式，该格式将精确存储数字以获取正确的值。

但是，对于精确的十进制表示，您要存储的值似乎比 postgres 允许的（似乎是 30）更大。如果您不想进行计算，只需存储它们（我承认这不是很常见的情况），您可以尝试将它们存储为字符串......（但这很难看......）

编辑

这个 to_char 问题似乎是一个已知的错误......

引用：

我对此的直接反应是 float8 值没有 57 位的精度。如果您希望该格式字符串做一些有用的事情，您应该将其应用于数字列而不是双精度列。

有可能我们可以设法使这个特定案例像您期望的那样工作，但总会有一些看起来相似的案例无法工作，因为精度不存在。

快速查看代码，您得到“0”的原因。是它在 15 位数字后四舍五入以确保它不会打印垃圾。对于值远小于 1 的情况，它可能会更聪明一些，但这不是一个简单的改变。

（从这里）

但是，我认为这无可辩驳。恕我直言，如果值适合类型，则双精度（确切地说是 IEEE754 64 位浮点）将始终具有 ~15 个有效十进制数字...

推荐阅读：

于 2013-09-18T10:16:36.293 回答