-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
doc(pg): document behavior of
bigdecimal
and rust_decimal
with ou…
…t-of-range values also add a regression test
- Loading branch information
Showing
6 changed files
with
99 additions
and
15 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,20 @@ | ||
#### Note: `BigDecimal` Has a Larger Range than `NUMERIC` | ||
`BigDecimal` can represent values with a far, far greater range than the `NUMERIC` type in Postgres can. | ||
|
||
`NUMERIC` is limited to 131,072 digits before the decimal point, and 16,384 digits after it. | ||
See [Section 8.1, Numeric Types] of the Postgres manual for details. | ||
|
||
Meanwhile, `BigDecimal` can theoretically represent a value with an arbitrary number of decimal digits, albeit | ||
with a maximum of 2<sup>63</sup> significant figures. | ||
|
||
Because encoding in the current API design _must_ be infallible, | ||
when attempting to encode a `BigDecimal` that cannot fit in the wire representation of `NUMERIC`, | ||
SQLx may instead encode a sentinel value that falls outside the allowed range but is still representable. | ||
|
||
This will cause the query to return a `DatabaseError` with code `22P03` (`invalid_binary_representation`) | ||
and the error message `invalid scale in external "numeric" value` (though this may be subject to change). | ||
|
||
However, `BigDecimal` should be able to decode any `NUMERIC` value except `NaN`, | ||
for which it has no representation. | ||
|
||
[Section 8.1, Numeric Types]: https://www.postgresql.org/docs/current/datatype-numeric.html |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,10 @@ | ||
#### Note: `rust_decimal::Decimal` Has a Smaller Range than `NUMERIC` | ||
`NUMERIC` is can have up to 131,072 digits before the decimal point, and 16,384 digits after it. | ||
See [Section 8.1, Numeric Types] of the Postgres manual for details. | ||
|
||
However, `rust_decimal::Decimal` is limited to a maximum absolute magnitude of 2<sup>96</sup> - 1, | ||
a number with 67 decimal digits, and a minimum absolute magnitude of 10<sup>-28</sup>, a number with, unsurprisingly, | ||
28 decimal digits. | ||
|
||
Thus, in contrast with `BigDecimal`, `NUMERIC` can actually represent every possible value of `rust_decimal::Decimal`, | ||
but not the other way around. This means that encoding should never fail, but decoding can. |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters