Thanks for the answer, Tom. Now it's become clear.
On Sat, 2017-09-02 at 16:20 -0400, Tom Lane wrote:
> The information you're missing here is that a numeric value carries a
> "display scale" value which indicates how many fractional digits to
> print.
> So "0.0" (scale 1) and "0.00000000000000000000" (scale 20) print
> differently, but they occupy the same amount of storage because the
> trailing zeroes are stripped for storage.
>
> Likewise, the documentation you started with was talking about the
> physical limits of the storage format, not about the actual behavior
> of any particular numeric operation.
You are right. I am rereading the official documentation of PostgreSQL
(9.6) to refresh it in memory. But didn't see any description about
"display scale", only about "scale", which is part of type definition.
I just checked it by google.
https://www.google.ru/search?q=site%3Ahttps%3A%2F%2Fwww.postgresql.org%
2Fdocs%2F9.6%2Fstatic%2F+%22display+scale%22&oq=site%3Ahttps%3A%2F%2Fww
w.postgresql.org%2Fdocs%2F9.6%2Fstatic%2F+%22display+scale%22&aqs=chrom
e..69i57j69i58.15543j0j8&sourceid=chrome&ie=UTF-8
"Display scale" exist only inside release notes. What is interesting,
there is even function scale(numeric) that shows parameter "display
scale" (according to release notes), but according to description in
documentation "scale of the argument (the number of decimal digits in
the fractional part)". May be this definitions are the same, but this
was not obvious. :) I checked:
=> select 1::numeric/3-0.33333333333333333333;
?column?
------------------------
0.00000000000000000000
=> select scale(1::numeric/3-0.33333333333333333333);
scale
-------
20
> As far as the 1/3 example goes, the division has to stop somewhere;
> we can't store an infinite number of digits. We could carry out the
> division to the physical limit of what numeric could store, but
> nobody
> would like that behavior.
Yep, it's reasonable, that's why I checked this example. But it is not
documented in description of numeric type and in chapter "Mathematical
Functions and Operators".
