-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
sql: add support for decimal arithmetic #1618
Comments
It's worth reading this: |
also, golang/go#12332 https://github.com/rin01/decnum It is a 128bits floating point decimal type. |
Thanks for the pointers. The SQL decimal/numeric type has user-specified precision. Postgres provides a very large range of allowed precisions (up to 131072 digits before the decimal point; up to 16383 digits after the decimal point). MySQL is more limiting (up to 65 total decimal digits with up to 30 after the decimal point). FYI, choosing a decimal number library to use is the easiest part of this change. The harder part is plumbing through support for the decimal type everywhere (table schemas, expression evaluation, indexing, etc). |
To get a better feel for the relative usages of the different libraries, I searched for the three mentioned above in the top 1000 open source Go repos, only to find that the only use of any of them is in Kubernetes. Spring's article on their library gave a good enough argument against |
Sounds like a good place to start. I imagine the usage of the decimal library should be fairly isolated and we'll be able to revisit this decision if it proves problematic. |
The SQL standard is relatively silent on what distinction there is between NUMERIC and DECIMAL. AFAICT, the only distinction is that NUMERIC assures that the precision is fixed, while DECIMAL only guarantees that at least the precision is maintained - more decimal digits are possible. In both cases the scale (digits to right of the decimal point are fixed.) Here's the literal text from the 2003 standard (unofficial copy): In any case, it would be useful to be specific as to what rules DECIMAL follows in CockroachDB, and whether NUMERIC is merely an exact synonym or not. They appear to be exact synonyms in Postgres. They appear to be exact synonyms in CockroachDB as well, but we should be explicit. Postgres and standard SQL (and now CockroachDB) also support the DEC abbreviation for DECIMAL. |
NUMERIC is an exact synonym for DECIMAL in CockroachDB. Making any subtle difference between the two seems like a recipe for confusion. |
Is this issue now fully addressed? I mean, the pull request was merged, so what's left? Besides the token scanner issue of recognizing large numbers so that they don't parse as FLOAT/INT. Is the encoding settled? I know there has been discussion related to DECIMAL vs. FLOAT encoding, but is it all settled now? Is the switch from shopspring to inf.Dec fully settled and accepted (merge has been done)? Also, this issue is currently listed in the 1.0 section of the Roadmap even though it sounds like it will be (mostly) in for Beta. |
This seems to have been addressed. Adding |
There are several Go decimal arithmetic libraries to choose from:
These libraries all have essentially the same implementation which is to use
math/big.Int
for the integer value and keep a separatescale int
parameter. The values are thus represented asunscaled * 10**(-scale)
.The text was updated successfully, but these errors were encountered: