Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Loss of decimal digits when converting from REAL to DECIMAL #129

Open
wants to merge 1 commit into
base: BABEL_3_X_DEV__PG_15_X
Choose a base branch
from

Conversation

bsatarupa
Copy link
Contributor

@bsatarupa bsatarupa commented Apr 16, 2023

Description

123456.25 requires 37 bits ( > 4 bytes) to get stored without any dataloss. REAL datatype can store upto 4B of floating point data; anything larger than that gets truncated while casting by underlying PG functions.

REAL datatype in sql server relaxes this storage restriction and hence can cast the entire data without any further dataloss.

Task: BABEL-3066
Signed-off-by: Satarupa Biswas [[email protected]]

  • Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is under the terms of the PostgreSQL license, and grant any person obtaining a copy of the contribution permission to relicense all or a portion of my contribution to the PostgreSQL License solely to contribute all or a portion of my contribution to the PostgreSQL open source project.

For more information on following Developer Certificate of Origin and signing off your commits, please check here.

123456.25 requires 37 bits ( > 4 bytes) to get stored without any dataloss.
REAL datatype can store upto 4B of floating point data; anything larger than
that gets truncated while casting by underlying PG functions.

REAL datatype in sql server relaxes this storage restriction and hence can
cast the entire data without any further dataloss.

Task: BABEL-3066
Signed-off-by: Satarupa Biswas [[email protected]]
if (sql_dialect == SQL_DIALECT_TSQL && extra_float_digits > 0)
float_to_shortest_decimal_buf(val, buf);
else
snprintf(buf, sizeof(buf), "%.*g", FLT_DIG, val);

Copy link
Contributor Author

Choose a reason for hiding this comment

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

similar logic can be found in float4out(); however in float4_numeric() the same was missing.

Copy link
Contributor

Choose a reason for hiding this comment

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

we need more test cases to validate that this right check. This change implies that when dialect is TSQL, always try to use extra digits for REAL datatype when casting from float4 to numeric. Is it really the case for all possible casting scenario from float4 to numeric?

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

Successfully merging this pull request may close these issues.

2 participants