You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
For postgres, we could use the numeric datatype, which I guess is what that comment is referring to.
For any backend that doesnt have a data type that can hold a u64, the u64 could be stored as a string, which will compare/sort correctly as long as the value is padded, and will aggregate reasonably well. We would likely want to put that impl behind a feature flag so people dont make use of the u64-as-string trick without being aware of the trade offs.
The text was updated successfully, but these errors were encountered:
https://github.com/Electron100/butane/blob/9377e31/butane_core/src/codegen/mod.rs#L455-L456 says
https://www.postgresql.org/docs/current/datatype-numeric.html bigint is the spec compliant signed 8 bytes, which can not hold a u64 without comparisons & aggregations being incorrect.
For postgres, we could use the
numeric
datatype, which I guess is what that comment is referring to.For any backend that doesnt have a data type that can hold a u64, the u64 could be stored as a string, which will compare/sort correctly as long as the value is padded, and will aggregate reasonably well. We would likely want to put that impl behind a feature flag so people dont make use of the u64-as-string trick without being aware of the trade offs.
The text was updated successfully, but these errors were encountered: