Number exceeds maximum value using rust_decimal.

[fabianboesiger]

I'm using sqlx (Postgres) with the rust_decimal crate (see #456) and got the error Number exceeds maximum value that can be represented. The number was stored in a Decimal before insertion into the database without any problems. Here is the relevant stack backtrace:

0: backtrace::backtrace::trace_unsynchronized
             at C:\Users\VssAdministrator\.cargo\registry\src\gh.neting.cc-1ecc6299db9ec823\backtrace-0.3.46\src\backtrace\mod.rs:66
   1: std::sys_common::backtrace::_print_fmt
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\sys_common\backtrace.rs:78
   2: std::sys_common::backtrace::_print::{{impl}}::fmt
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\sys_common\backtrace.rs:59
   3: core::fmt::write
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libcore\fmt\mod.rs:1076
   4: std::io::Write::write_fmt<std::sys::windows::stdio::Stderr>
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\io\mod.rs:1537    
   5: std::sys_common::backtrace::_print
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\sys_common\backtrace.rs:62
   6: std::sys_common::backtrace::print
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\sys_common\backtrace.rs:49
   7: std::panicking::default_hook::{{closure}}
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\panicking.rs:198  
   8: std::panicking::default_hook
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\panicking.rs:218  
   9: std::panicking::rust_panic_with_hook
             at /rustc/d3fb005a39e62501b8b0b356166e515ae24e2e54\/src\libstd\panicking.rs:486  
  10: std::panicking::begin_panic<str*>
             at C:\Users\Fabian\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libstd\panicking.rs:410
  11: rust_decimal::decimal::Decimal::from_i128_with_scale
             at C:\Users\Fabian\.cargo\registry\src\gh.neting.cc-1ecc6299db9ec823\rust_decimal-1.7.0\src\decimal.rs:199
  12: sqlx_core::postgres::types::decimal::{{impl}}::try_from
             at C:\Users\Fabian\.cargo\git\checkouts\sqlx-f05f33ba4f5c3036\67099d9\sqlx-core\src\postgres\types\decimal.rs:81
  13: core::convert::{{impl}}::try_into<sqlx_core::postgres::types::numeric::PgNumeric,rust_decimal::decimal::Decimal>
             at C:\Users\Fabian\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\src\rust\src\libcore\convert\mod.rs:595
  14: sqlx_core::postgres::types::decimal::{{impl}}::decode
             at C:\Users\Fabian\.cargo\git\checkouts\sqlx-f05f33ba4f5c3036\67099d9\sqlx-core\src\postgres\types\decimal.rs:172
  15: sqlx_core::row::Row::try_get<sqlx_core::postgres::row::PgRow,rust_decimal::decimal::Decimal,str*>

[abonander]

What is the value of the number, please?

[fabianboesiger]

It seems to occur at multiple values, one of them is 17.905625985174584660842500258.

[abonander]

That's pretty close to the precision limit, extra trailing zeros from the base-10000 wire representation might be pushing it over.

We can work on this, but keep in mind that Decimal has fixed maximum precision so you probably want to round to a certain number of significant figures anyway. If you need arbitrary precision, use BigDecimal instead.

[fabianboesiger]

Yes, I know that the Decimal datatype has fixed precision. But as the number was stored as a Decimal before insertion, it should be possible to select it from the database into a Decimal again without a Number exceeds maximum value that can be represented error.

[abonander]

This is likely because we deal with the number in base-100 after decoding from the wire protocol so its precision may be extended to the next even power of 10. We probably need to divide the value by 10 to get rid of superfluous trailing zeroes.

[pimeys]

Rust-decimal also has a limit for scale that is 28. You can't go over that. Maybe consider using bigdecimal instead?

[Swoorup]

Is there a workaround for this atm? Currently hitting it,

[aradhya-variational-io]

any recommended solutions here other than using BigDecimal? I was able to confirm this is happening due to the trailing zeroes.

[fabianboesiger]

@aradhya-variational-io my workaround was to just use round_dp to round the decimal to my required precision before storing it in the database.