Numerics in Postgres bigger than 2<<128 crash Prisma/Quaint

[snf]

Bug description

Numeric types in Postgres should be able to hold up to 131072 digits before the decimal point; up to 16383 digits after the decimal point . The current limit by Prisma is (2 << 128) - 1 and it currently crashes if the limit is reached.

I reported it here in quaint with more specific details: prisma/quaint#345 . Opening this one for two reasons, first to track the issue and second so people suggest possible solutions.

How to reproduce

1. create Numeric(78,0)
2. insert big value, for example: "3618502788666131106986593281521497120414687020801267626233049500247285301248"

Expected behavior

No response

Prisma information

Use big numeric in any query

Environment & setup

• OS:Debian
• Database: PostgreSQL
• Node.js version: v12.22.5

Prisma Version

prisma                  : 3.8.1
@prisma/client          : 3.6.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : 34df67547cf5598f5a6cd3eb45f14ee70c3fb86f
Studio                  : 0.452.0

Stacktrace

thread 'tokio-runtime-worker' panicked at 'called `Option::unwrap()` on a `None` value', /root/.cargo/git/checkouts/quaint-9f01e008b9a89c14/05eb0ac/src/connector/postgres/conversion/decimal.rs:81:39
stack backtrace:
   0: rust_begin_unwind
             at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/std/src/panicking.rs:517:5
   1: core::panicking::panic_fmt
             at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/panicking.rs:101:14
   2: core::panicking::panic
             at /rustc/59eed8a2aac0230a8b53e89d4e99d55912ba6b35/library/core/src/panicking.rs:50:5
   3: <quaint::connector::postgres::conversion::decimal::DecimalWrapper as postgres_types::ToSql>::to_sql
   4: quaint::connector::postgres::conversion::<impl postgres_types::ToSql for quaint::ast::values::Value>::to_sql
   5: quaint::connector::postgres::conversion::<impl postgres_types::ToSql for quaint::ast::values::Value>::to_sql_checked
   6: postgres_protocol::write_nullable
   7: tokio_postgres::query::encode
   8: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
   9: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  10: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  11: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  12: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  13: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  14: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  15: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  16: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  17: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  18: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  19: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  20: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  21: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  22: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  23: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  24: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  25: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  26: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  27: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  28: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  29: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  30: <core::future::from_generator::GenFuture<T> as core::future::future::Future>::poll
  31: tokio::runtime::task::harness::Harness<T,S>::poll
  32: tokio::runtime::thread_pool::worker::Context::run_task
  33: tokio::runtime::thread_pool::worker::Context::run
  34: tokio::macros::scoped_tls::ScopedKey<T>::set
  35: tokio::runtime::thread_pool::worker::run
  36: tokio::loom::std::unsafe_cell::UnsafeCell<T>::with_mut
  37: tokio::runtime::task::harness::Harness<T,S>::poll
  38: tokio::runtime::blocking::pool::Inner::run
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.

[matthewmueller]

Did you create Numeric(78,0) yourself or through the Prisma Schema?

[snf]

I created it myself and then used db pull to create the schema which guessed the right type I think?:

value Decimal @db.Decimal(78, 0)

[wagmiwiz]

Seeing the same with Postgres and Decimal @db.Decimal(78, 0) in schema.

[eddiexbank]

is there any update about this bug?

[zipzapzanigan]

also hitting this issue...

[Weakky]

Hey,

This was fixed by prisma/quaint#379 and should be available in the next release.

Closing now, thanks for reporting 🙏