Skip to content

fix: Precision loss on extremely large floating-point numbers #3093

New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Open
wants to merge 2 commits into
base: master
Choose a base branch
from

Conversation

SevInf
Copy link

@SevInf SevInf commented Nov 6, 2023

Sets extra_float_digits setting to 1 when connecting to DB. For older
(<12) Postgres, this should be enough to cover all values JS can store
preciesely. For 12+ postgres this setting should have no effect.

Fix #3092

Sergey Tatarintsev and others added 2 commits November 6, 2023 15:26
Sets `extra_float_digits` setting to 1 when connecting to DB. For older
(<12) Postgres, this should be enough to cover all values JS can store
preciesely. For 12+ postgres this setting should have no effect.

Fix brianc#3092
@@ -26,6 +26,7 @@ const startup = (opts: Record<string, string>): Buffer => {
}

writer.addCString('client_encoding').addCString('UTF8')
writer.addCString('extra_float_digits').addCString('1')
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this belongs in pg’s use of startup instead of in pg-protocol. (Side benefit: fewer/no other tests to update, since that’s at least part of why CI is failing right now.)

It also needs to be higher than 1 (take 0.42467013940651843 as a random example), with an accordingly stricter test case. I don’t have time right now to figure out exactly how much precision is enough, but setting it to 3 (https://www.postgresql.org/docs/11/runtime-config-client.html#GUC-EXTRA-FLOAT-DIGITS) is probably fine.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Precision loss on numbers close to MAX_SAFE_INTEGER on Postgres < 12
2 participants