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

GH-120: Add initial Decimal32/Decimal64 implementation #121

Merged
merged 3 commits into from
Sep 13, 2024

Conversation

zeroshade
Copy link
Member

@zeroshade zeroshade commented Sep 10, 2024

Fix GH-120

Rationale for this change

Widening the Decimal128/256 type to allow for bitwidths of 32 and 64 allows for more interoperability with other libraries and utilities which already support these types. This provides even more opportunities for zero-copy interactions between things such as libcudf and various databases.

What changes are included in this PR?

This PR contains the basic Go implementations for Decimal32/Decimal64 types, arrays, builders and scalars. It also includes the minimum necessary to get everything compiling and tests passing without also extending the acero kernels and parquet handling (both of which will be handled in follow-up PRs).

Are these changes tested?

Yes, tests were extended where applicable to add decimal32/decimal64 cases.

@zeroshade zeroshade requested review from kou and joellubi September 10, 2024 20:38
Copy link
Member

@kou kou left a comment

Choose a reason for hiding this comment

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

+1

We need integration test CI for this, right?

I'll prepare it.

.gitignore Show resolved Hide resolved
@zeroshade
Copy link
Member Author

We need integration test CI for this, right?

Yea, the corresponding C++ PR for decimal 32/64 has the change to datagen.py to add these cases to the integration tests, and then when we update the CI integration tests to use this repo instead of the main arrow repo, we can unskip Go.

}

func NewDecimalType(id Type, prec, scale int32) (DecimalType, error) {
switch id {
case DECIMAL32:
debug.Assert(prec <= int32(decimal.MaxPrecision[decimal.Decimal32]()), "invalid precision for decimal32")
Copy link
Contributor

Choose a reason for hiding this comment

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

should this condition be an error? or is the DecimalNType informational

Copy link
Member Author

Choose a reason for hiding this comment

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

The assumption being made is that if a user is explicitly calling NewDecimalType they know what they are doing, so we only perform the precision validation in debug mode for performance.

@zeroshade zeroshade merged commit f17963e into apache:main Sep 13, 2024
17 checks passed
@zeroshade zeroshade deleted the go-decimal32-64 branch September 13, 2024 14:36
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.

Add initial Decimal32/Decimal64 implementation
4 participants