Data Type: `NUMERIC`
About
CrateDB gained a new data type NUMERIC. Most probably, we want to support it here in one way or another.
References
- https://github.com/crate/sqlalchemy-cratedb/issues/163
- https://github.com/crate-workbench/meltano-target-cratedb/issues/52
It is probably still the right choice to serialize Decimal values as strings, because there is no other way to marshal them through JSON?
https://github.com/crate/crate-python/blob/8a3bf388e07e463a9ea3f451a4bdb6c64f2242fd/src/crate/client/http.py#L95-L96
In this case, I guess it will be safe to close this issue for the DB API driver, but check https://github.com/crate/sqlalchemy-cratedb/issues/163 instead, if there is something to do for SQLAlchemy, which is more likely?
/cc @matriv, @seut
If we have the same behavior that we encountered here: https://github.com/crate/crate/pull/16843 I agree to go with strings.
Thank you. Then, there will be nothing to update or improve, other than the documentation perhaps, also on the Python driver at a relevant spot?
-- https://github.com/crate/crate/pull/16843
As you advise that HTTP/JSON transport may loose precision, may I ask if it would be expectably different when using the PostgreSQL interface?
As you advise that HTTP/JSON transport may loose precision, may I ask if it would be expectably different when using the PostgreSQL interface?
Yes, the issue is completely related to HTTP/JSON only.
and to be more precise, http streams the full number (reaches the client), but the application/json MIME type directive is the one that truncates digits.
As CrateDB supports NUMERIC/DECIMAL types for quite some time (only the support to store numeric values was added recently), I wonder what this issue is about, what is missing?
Probably we want to change the related test case to use a NUMERIC column data type in the table definition.