[Bug]: Postgres | BigInt & Numeric datatypes returning wrong values

[Aishwarya-U-R]

Is there an existing issue for this?

• [X] I have searched the existing issues

Description

BigInt & Numeric datatype columns are inserting wrong value into table column:

Actual values: bigint - 9223372036854775807 numeric - 2147483647.2147483647

Retrieved values: bigint - 9223372036854776000 numeric - 2147483647.2147484

Steps To Reproduce

1. Connect to a Postgres ds
2. Create table - create table numeric (id smallint not null primary key, bigintId bigint not null, demimalId decimal not null, numericId numeric not null)
3. Insert values - INSERT INTO public."numeric" ("id", "bigintid", "demimalid", "numericid") VALUES (1, 9223372036854775807, 865456.987654567, 2147483647.2147483647);
4. Run select query on the table & map to a table widget for viewing
5. Observe the values of column : Wrong values are displayed
6. Expected: If within the range - actual values inserted by user should be stored in table & retrieved as-well

Public Sample App

No response

Version

Prod/Release v1.7.2

[subrata71]

RCA

According to my findings, I think the problem solely lies in the presentation layer. I have found that the data are being inserted into Postgres database without being truncated. Also, the /execute API returns the data from the Postgres database keeping it unchanged.

And the problem turns up due to an early rounding issue on the client side. (IMO)

Datatype	Expected	Actual	Findings
bigint	9223372036854775807	9223372036854776000	For bigint datatype ,the client-side rounds it at the 16th digit (from left to right)
numeric	2147483647.2147483647	2147483647.2147484	For numeric datatype, the client-side rounds it up to 7 digits after the decimal point

Postgres DB (Checked with Datagrip tool)

Server returning data properly (/execute API Response)

Side by side In the Network->Response Tab we can see that the server is returning the data as expected.

Response Tab (Chrome) (Zoomed In)

[sumitsum]

Lowering the priority of this issue from critical to High since the impact of the issue is limited and it does not break any application.

[sumitsum]

Related issue: https://github.com/appsmithorg/appsmith/issues/5743